1. Requirements Analysis CS 414 – Software Engineering I Donald J. Bagert Rose-Hulman Institute of Technology January 7, 2003

2. CS 414 Software Engineering I - Requirements Analysis - January 7, 20032 Outline Engineering of Requirements Requirements Elicitation Requirements Analysis Specification Screen Prototyping Review, Negotiation and Agreement Requirements Management Validation Test Planning Summary

3. CS 414 Software Engineering I - Requirements Analysis - January 7, 20033 Engineering of Requirements The development and management of requirements is something that is much the same across disciplines e.g. –The entire system must always be taken into account –The client frequently supplies vague, incomplete and sometimes contradictory information –The client often has unrealistic expectations –Requirements must be specified and subsequently matched to design –The requirements may change due for a variety of reasons, and must be managed throughout the project process This process is called “requirements engineering”

4. CS 414 Software Engineering I - Requirements Analysis - January 7, 20034 Requirements Elicitation Elicitation is determining the system requirements through interaction with the client and other project stakeholders This is a non-trivial task, since the information supplied is often –incomplete –inconsistent –ambiguous

5. CS 414 Software Engineering I - Requirements Analysis - January 7, 20035 Requirements Elicitation (continued) Primary goals of elicitation: –Determining system feasibility –Determining the technical environment of the system –Creating a list of desired functions of the system –Determining any constraints on the system (“non-functional requirements”) –Compiling a list of scenarios that will occur during use of the system

6. CS 414 Software Engineering I - Requirements Analysis - January 7, 20036 Requirements Analysis Organizes the elicitation results Categorizes and prioritizes the system requirements Determines if the requirements are complete, consistent and unambiguous

7. CS 414 Software Engineering I - Requirements Analysis - January 7, 20037 Specification The Requirements Specification Document (RSD) is the end result of the analysis process Major components of the specification include: –System model –User characteristics –Requirements Functions Constraints –Use Cases –Tracing (cross-referencing) of requirements and use cases to client requirements

8. CS 414 Software Engineering I - Requirements Analysis - January 7, 20038 Specification (continued) Types of System Models –Data-flow diagrams –Control-flow diagrams (system behavior) –Entity-relationship diagrams –High-level software architecture

9. CS 414 Software Engineering I - Requirements Analysis - January 7, 20039 Specification (continued) Use cases –Creating using the scenarios determined during elicitation –Sections Overview Preconditions Scenario Details and Context Postconditions Exception Handling

10. CS 414 Software Engineering I - Requirements Analysis - January 7, 200310 Specification (continued) The Requirements Specification for this course includes a section on the scope of the project since there is a time-limit involved

11. CS 414 Software Engineering I - Requirements Analysis - January 7, 200311 Screen Prototyping Screen Prototypes: –Should be submitted to the client in addition to the Requirements Specification –Gives the client a better idea of what is being proposed –Can be quickly created using languages such as Visual Basic and Tcl/Tk

12. CS 414 Software Engineering I - Requirements Analysis - January 7, 200312 Review, Negotiation and Agreement Both the vendor and the client should review the Requirements Specification Document Internal review can be in the form of an inspection, which should be done (if time permits) before submission to the client

13. CS 414 Software Engineering I - Requirements Analysis - January 7, 200313 Review, Negotiation and Agreement (continued) Some of the questions to be asked: –Are all sections of the template included? –Has a clear, brief summary is given of the client's needs supplied? –Is the current client system diagram accurate? –Are the user characteristics are given clearly and completely? –Are all requirements are well organized, clear, understandable, unambiguous, consistent, non-conflicting, necessary, and non- redundant? – Are all diagrams in the requirements use standard notation and are also clear and complete? –Are the requirements are appropriately numbered and cross-referenced making it easy to ensure all requirements have been met in the project?

14. CS 414 Software Engineering I - Requirements Analysis - January 7, 200314 Review, Negotiation and Agreement (continued) The client should then review the Requirements Specification, screen prototypes, Project Plan and budget The client and vendor then negotiate a formal written agreement, which includes: –Functionality to be included in the delivered software –Artifacts to be delivered –Schedule for delivery of artifacts –Amount to be paid by the client to the vendor, and schedule of payments

15. CS 414 Software Engineering I - Requirements Analysis - January 7, 200315 Requirements Management Changes to requirements after the formal agreement is reached Traceability of RSD elements to the Design Document and (indirectly) to other artifacts

16. CS 414 Software Engineering I - Requirements Analysis - January 7, 200316 Validation Test Planning Validation answers the question “Have we got the right product?” –That is, validation of an artifact is the process of determining whether that artifact meets the customer requirements –A Validation Test Plan defines the set of tests to be done to validate the software Validation test cases can be largely created from the RSD use cases, and should always be from the user point-of-view Should be created as soon as possible after the formal agreement is reached (to avoid bias from the design) Modified as necessary as part of requirements management Implemented as the last step of testing by the project team

17. CS 414 Software Engineering I - Requirements Analysis - January 7, 200317 Summary Requirements engineering refers to the development and management of requirements across disciplines The client frequently supplies vague, incomplete and sometimes contradictory information, and often has unrealistic expectations Requirements elicitation is the process of determining the system requirements through interaction with the client and other project stakeholders Analysis organizes the elicitation results and categorizes and prioritizes the system requirements

18. CS 414 Software Engineering I - Requirements Analysis - January 7, 200318 Summary (continued) The Requirements Specification Document is the end result of the analysis process The Requirements Specification, screen prototypes, Project Plan and budget should be submitted to the client for review The client and vendor then negotiate a formal written agreement

19. CS 414 Software Engineering I - Requirements Analysis - January 7, 200319 Summary (continued) Requirements management is need to handle changes to requirements after the formal agreement is reached, and to the trace requirements to design and other artifacts The Validation Test Plan is created from the requirements in order to eventually test the software from the user’s point-of-view