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

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

CS 414 Software Engineering I - Requirements Analysis - January 7, 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”

CS 414 Software Engineering I - Requirements Analysis - January 7, 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

CS 414 Software Engineering I - Requirements Analysis - January 7, 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

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

CS 414 Software Engineering I - Requirements Analysis - January 7, 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

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

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

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

CS 414 Software Engineering I - Requirements Analysis - January 7, 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

CS 414 Software Engineering I - Requirements Analysis - January 7, 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

CS 414 Software Engineering I - Requirements Analysis - January 7, 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?

CS 414 Software Engineering I - Requirements Analysis - January 7, 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

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

CS 414 Software Engineering I - Requirements Analysis - January 7, 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

CS 414 Software Engineering I - Requirements Analysis - January 7, 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

CS 414 Software Engineering I - Requirements Analysis - January 7, 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

CS 414 Software Engineering I - Requirements Analysis - January 7, 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