1 / 19

Requirements Analysis

Understand the crucial processes of requirements elicitation, analysis, and specification in software engineering projects to ensure project success and stakeholder satisfaction.

aacosta
Download Presentation

Requirements Analysis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. 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

  4. 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

  5. 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

  6. 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

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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

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

  14. 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

  15. 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

  16. 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

  17. 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

  18. 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

  19. 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

More Related