What are Requirements? SENG1031 Software Engineering Workshop 1. My Notes. System Overview: The Big Picture

Transcription

1 What are Requirements? SENG1031 Software Engineering Workshop 1 Requirements, An Overview Peter Ho CSE, UNSW 5 Aug 2010 Requirements are a collection of statements defined by the System Stakeholders. These statements define what stakeholders expect from an: Implemented; and Deployed system. The requirements can be characterised into: Functional Requirements; and Non-Functional Requirements. System Overview: The Big Picture User groups Interfaces System Platform: HW, OS, DB Spreadsheet Data requirements: System state: Database, comm. states Input/output formats Ext. products: Sensors, dev. Special SW Functional requirements, each interface: Record, compute, transform, transmit Theory: F(input, state) -> (output, state) Function list, pseudo-code, activity diagram Screen prototype, support tasks xx to yy Quality reqs: Performance Usability Maintainability... Other deliverables: Documentation Install, convert, train... Managerial reqs: Delivery time Legal Development process... Helping the reader: Business goals Definitions Diagrams... Soren Lausen, Software Requirements, Styles and Techniques, Addison-Wesley, 2002, p13

2 System Overview: The Big Picture Price For Getting it Wrong A project consists of: Data Requirements (DBs, comms, i/o) Functional Requirements F (input, state) (output, state) Quality or Non-Functional Requirements Other Deliverables Documentation, Install guides etc Managerial Requirements contractual arrangements, arbitration, mediation Helping the Reader (Infrastructure) Business goals, background, rationale, history etc Loss of data (Data Requirements failure) Loss of functionality (Functional Requirements failure) Failure to meet business goals (Business Requirements failure) Poor performance and reliability (NF-Requirement failure) Business relationship crisis (Managerial Requirements failure) Poor user acceptance (Infrastructure failure) Remember: Most system failures can be traced back to some form of Requirements Failure. Defining the Product: Domain Business domain Domain Actors? Platform Clients Product User activities Control computers Domain I/O Product I/O Elevators Soren Lausen, Software Requirements, Styles and Techniques, Addison-Wesley, 2002, p21

3 Definitions Drawing the Line Know what the customer wants Definitions Product: The thing to be built (may include s/w and h/w) Domain (inner): Consists of the product and its surrounds (eg, users, other systems) Domain (outer): Second level users (clients) and systems Business domain Clients Domain Product Control computers The Nexus Product-level Requirements: specifies the product Domain-level Requirements: specifies the boundaries/scope for the system and requirements to support those activities. User activities Soren Lausen, Software Requirements, Styles and Techniques, Addison-Wesley, 2002, p23 What are Requirements? Requirements are statements that say: What the system should do without specifying how what the system cannot exist without

4 Different Levels of Detail Goal-level Requirements Consists of Business Goals eg: Improve client responsiveness Domain-level Requirements Outlines the tasks involved and the required support for these tasks eg: It will support client order status inquiries. The product will also support the tracking of nameplates in the production cycle to update order status. Product-level Requirement Specify what comes in and goes out of the product (ie identify the function or feature) eg: The product will have a function for updating client order status during the manufacturing process. Design-level Requirements Specify product interface in detail eg:the product shall provide a client order status screen with a layout shown in diagram xx. Hierarchy of Requirements!"#$%$&'&$( )&*+,-&.&/01( 2".#,/%$&'&$( )&*+,-&.&/01( 3-"4+50%$&'&$( )&*+,-&.&/01( 2&1,6/%$&'&$( )&*+,-&.&/01( 7!8,69$:(;<10-#50( 7!=-"#4( 7!8,69($&'&$( 7!>?&5,@5( 7!A#--"B( 7!C"B($&'&$( Choosing the Right Level Finding the Balance: Difficult - experience helps Goal-level requirements are usually broad or abstract but are necessary to provide focus and guidance Guided by the Goal-level requirements, a good collection of Domain-level requirements is essential and sets the bounds of the system Product-level requirements are necessary to expand upon Domain-level requirements Design-level requirements should be used only where required Organize and Management your requirements otherwise: You won t see the forest for the trees!

5 Sanity Check Requirements Tree Sanity Check Are the requirements sufficient to develop a design specification? Do the requirements limit design choices? Can all the requirements be traced? Never forget to ask Why. Requirements Tree Observations: All Goal-level requirements must be described by more specific (detailed) requirements All lower level requirements must belong to a Goal-level (abstract) requirement There should be no orphaned requirements (nodes) Requirements are numbered to show heredity and to help with traceability (see next slide)

6 Requirements Numbering A numbering system is used to represent requirement hierarchy. Each requirement should have a unique number Hierarchical requirements can be numbered using a dot notation, eg: 1, 1.1, 1.2, 2, 2.1, 2.2 etc The hierarchy shows different levels of abstraction. Child requirements providing greater detail. The numbers should facilitate requirements traceability Prefixes like GL (Goal), DN (Domain), PD (Product) and DZ (Design) should also be used to indicate the requirement s hierarchy. Lots of numbering schemes available, apply your chosen scheme consistently Renumbering requirements should be avoided Functional Requirements Definition These are statements that describe the system s scope or boundary necessary business functions required data structures These are functions that the system cannot exist without F (input, SystemState) (output, NewSystemState) Non-Functional Requirements Definition These are statements that specify how well the system performs its intended functions, for example they include: Performance: system response time, hardware performance etc Usability: ease of use, easy to learn, etc Maintenance: defects repair, add new functionality, etc NF-Requirements specify: The quality attributes and are just as important as Functional Requirements.

7 Splitting The Requirements What s the next step? Identify the Function from the Non-functional Requirements Why? It helps with: Requirements prioritizing Determine Requirements dependencies Making the Distinction Most functional requirements are obvious! Consider the following Goal-level requirement: Improve client responsiveness Functional Requirement: Easy to see that the following is a Functional Requirement because it is an essential core requirement: The product shall have a function for updating client order status during the manufacturing process. Non-Functional Requirement: While the following is a Non-functional requirements: The product shall respond to client enquires promptly. Non-obvious Requirements Is this a Functional or Non-Functional Requirement? The product shall provide user with visual feedback on delayed transactions Ask yourself the following questions: 1 Is this an essential function? 2 Would a failure to implement this function prevent the system from fulfilling its goal? Justification: Whatever the answer, you must be able to justify your decision.

8 Dependency Matrix Identifying Risks Requirements must never overlap or conflict with other requirements. Build a dependency matrix: Requirements R1 R2 R3 R4 R1 R2 Conflict Unused R3 R4 Overlap Overlap All projects are constraint by Risk and Resources (Time and Money) Not all Requirements can be realized Risk Analysis identifies requirements that are likely to cause development difficulties Risk Examples: technical risks, performance risk, DB integrity risk, development process risk, political risk, legal risk, volatility risk Priority Matrix Work with your client to determine Requirements Priority based on Identified Risks Procedure: Consult the Requirements Dependency Matrix Rank the requirements using a suitable numeric scale Iterate process until there s a quorum Remember: All Projects are a compromise of requirements IMPORTANT Make sure the client signs off on the final set of requirements

9 Final Checklist 1 Categorize & organize requirements into a hierarchy 2 Identify the Functional from Non-Functional Requirements 3 Find, correct or eliminate inconsistent, vague and contradicting requirements 4 Build Requirements Dependency Matrix 5 Establish requirement priorities IMPORTANT Requirements traceability is Paramount, iterate through the checklist whenever there s a change Change Management Change is inevitable, it can t be avoided so managing it is important. When can change occur? Change can happen even after the requirements has been signed off by the client A formal business case must be made for each change request Consequences of change: Any change will have an impact on: the cost, resources duration and the feasibility of the project The whole project must be reviewed with every proposed change. The client must be made aware of the impact and signed off if they are to proceed with the requested change Change Management Integrating the Change: All change request and changes must be documented Iterate through Final Checklist again

10 Requirements Document Typical Requirements Template A Requirements Document is a tangible outcome of the requirements elicitation process. The document must also address project issues both at the start and at the end of the document There are both ANSI and IEEE standards that define templates for requirements documents. 1. Project Preliminaries Purpose and Scope Business context Stakeholders Ideas for solutions Doc overview 2. Functional Requirements System Scope Functional Req Data Req 3. NF-Requirements Interface Req Performance Req Security Req Operational Req Other Constraints 4. Project Matters Open Issues Budget & Schedule Appendices Glossary & References Modified Template: In this course we will be using a modified version of a typical requirements template.