Requirements Engineering Chapter 4 PDF

REQUIREMENTS ENGINEERING 1 JIMMA UNIVERSITY JIMMA INSTITUTE OF TECHNOLOGY FACULTY OF COMPUTING AND INFORMATICS CHAPTER FOUR REQUIREMENTS SPECIFICATION AND DOCUMENTATION  Topics we will cover Requirement...

REQUIREMENTS ENGINEERING 1 JIMMA UNIVERSITY JIMMA INSTITUTE OF TECHNOLOGY FACULTY OF COMPUTING AND INFORMATICS CHAPTER FOUR REQUIREMENTS SPECIFICATION AND DOCUMENTATION  Topics we will cover Requirements Specification Requirements Document Methods for requirements documentation User Story Software requirement specification Free documentation in unrestricted natural language Disciplined documentation in structured natural language  Requirements Specifications 3 A software requirements specification is a collection of the set of all requirements that are to be imposed on the design and verification of the product/software. Requirements specification: It's the activity of writing down the requirements gathered during the elicitation and analysis activity into a document that defines a set of requirements. Input for requirement specification are outputs of requirement analysis & negotiation Output of requirement specification is a complete description of a system to be developed: : Requirements Document  Requirements Specifications During requirements specification : Define your product's purpose and scope. Describe what you're building. Details the requirements. Supporting information. Results a requirements document  Requirements Document Requirements document is a reference document. Once a requirement document is approved by the customer, Any subsequent controversies are settled by referring the document. Purpose of requirement document: Interface (communication) between the Customer, requirement engineers Analyst, designers, system developers, testers and maintainers. Agreement between Purchaser and Supplier Support verification and validation of requirements. Support system testing activities Support project management activities Controlling the evolution of overall system  Characteristics of a Requirements Document A good requirement document is: Clear, Complete, Accurate , Consistent, Traceable, Relevant  Problems without a requirement document The important problems that an organization would face if it does not develop a requirement document are as follows: Without developing a requirement document, the system would not be implemented according to customer needs. Software developers would not know whether what they are developing is what exactly required by the customer. It will be very much difficult for the maintenance engineers to understand the functionality of the system. It will be very much difficult for user document writers to write the users’ manuals properly.  Methods for Software requirements Specification 8 The formality and format of a specification varies with the size and the complexity of the software to be built. For large systems, user story or disciplined documentation in structured natural language may be the best methods. For small systems or product, free documentation in unrestricted natural language  User Story A User Story is a requirement expressed from the perspective of an end-user goal. The User Story format has become the most popular way of expressing requirements in Agile for a number of reasons: It focuses on the viewpoint of a role who will use or be impacted by the solution It defines the requirement in language that has meaning for that role It helps to clarify the true reason for the requirement It helps to define high level requirements without necessarily going into low level detail too early  User Story format As a < role>, I want, So that Example: As a Home seeker, I want to view home details so that I can assess the suitability of the home for my needs.  Free documentation in unrestricted natural language Unconstrained prose writing in natural language. Unlimited expressiveness, communicability, no training needed Prone to many of the spec errors & flaws Cons: Frequent confusions among logical connectives in natural language and order of the contents. Example: case analysis: if Case1:then AND if Case2: then  Use Disciplined documentation in structured in natural languages Use standardized statement templates. Title of standard: “IEEE Recommended Practice for Software Requirements Specification” Describes the content and qualities of a good SRS Presents several sample SRS outlines IEEE 830-1998 Standard – Structure of the SRS IEEE 830-1998 Standard – Structure of the SRS IEEE 830-1998 Standard – Structure of the SRS IEEE 830-1998 Standard – Structure of the SRS  User Story + SRS Stories from user stories, and design and implementation tasks from the SRS, along with testing tasks from user stories.  Key Points User Story Requirements Specification Requirements Document Methods for Software requirements Specification Any Question?