Requirements Analysis CS 414 Software Engineering I Donald

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, 2003

Outline • • • Engineering of 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, 2003 2

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, 2003 3

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, 2003 4

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, 2003 5

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, 2003 6

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, 2003 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, 2003 8

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, 2003 9

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, 2003 10

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, 2003 11

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, 2003 12

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 nonredundant? – 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, 2003 13

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, 2003 14

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, 2003 15

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, 2003 16

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, 2003 17

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, 2003 18

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