Teaching slides Chapter 4 Chapter 4 Software Requirement

Teaching slides Chapter 4

Chapter 4 Software Requirement Specifications Contents • • Introduction Software engineering methodologies and requirements management – – – • • Requirement management in XP Requirement management in Scrum Requirement management in Waterfall Implementation of the requirements Requirement Types Sources of requirements Categories of users Software requirement lifecycle Requirement gathering (elicitation) Requirement analysis Requirement specification – Use cases – Relevance of use cases in software design – Use case Example • Requirement management

Chapter 4 Software Requirement Specifications Introduction Any software product is built based on user or customer requirements. If there are no user/customer requirements then you can not create a software product. Software requirements are gathered from the users by conducting interviews or using emails. A questionnaire is used to collect all user requirements. Generally gathered user requirements are in unstructured format. Once all requirements are gathered then these requirements need to be converted into standard specifications using a structured format. These specifications are known as software requirement specifications. This is required to make each software requirement crystal clear so that there are no chances of misunderstanding any software requirement. The software design is based on these software requirement specifications.

Chapter 4 Software Requirement Specifications Introduction Software requirement specifications can be in form of text, use cases or any suitable form which can be easily used in creating software designs. When all software requirement specifications are stored in a document then this document is known as software requirement specification (SRS) document. e. Xtreme Programming and Scrum use a different term “user stories” which are essentially software requirement specifications. Sometimes a term known as software feature is also used. In Scrum a term known as a product backlog is used. A product backlog contains a list of all software requirement specifications for a project. There is also a sprint backlog. A sprint backlog contains all requirement specifications for a sprint (iteration).

Chapter 4 Software Requirement Specifications Software architecture & implementation details

Chapter 4 Software Requirement Specifications Software requirement specifications should never include information as to how a software requirement specifications should be implemented (how the software design will be made). One reason is that software requirement specifications are made by business analysts. They have no idea about software design. The other reason is that it is best to create good software requirement specifications first. Once they are ready only then implementation considerations should be made.

Chapter 4 Software Requirement Specifications Changed requirements require changes in software architecture & source code

Chapter 4 Software Requirement Specifications On projects where Waterfall software engineering methodology is used; there is possibility of a requirement getting changed. This happens because the customer or users want a change in a software requirement which they stated earlier. When this happens then the software design and source code if already implemented for that requirement may need to be changed as well. This will lead to rework. On Agile projects, change requests in software requirements do not happen. This is because most software requirements are very fresh (hardly 10 to 15 days old) when they are implemented (designed and constructed). Thus there is no need for any change requests in requirements on these projects.

Chapter 4 Software Requirement Specifications Software requirement types

Chapter 4 Software Requirement Specifications Requirements are of 2 types: functional and non-functional requirements. Functional requirements are those requirements which are directly related to software features which are used by users of the software product. Non-functional requirements are those requirements which can not be related to any software features but instead they are useful in running the software product. Some examples of non-functional requirements include performance, security, usability etc. Performance requirements are helpful in making sure that the user gets output from the software product within reasonable amount of time after each user interaction. Security requirements ensure that there is no data theft or dangerous activity in the software product due to unauthorized access.

Chapter 4 Software Requirement Specifications Sources of software requirements

Chapter 4 Software Requirement Specifications There could be many sources from where software requirements can be picked up. It depends on the situation on hand. If a legacy system is already being used then the software requirements can come directly from the legacy system. If the software product will be used by the customer then the software requirements will come from the users who are employees of the customer. If the software product is being developed to be used by customers of the customer then the software requirements will come from these customers of the customer (market).

Chapter 4 Software Requirement Specifications Software requirement management cycle

Chapter 4 Software Requirement Specifications Software requirements go through many transformations during their existence. Software requirements are first gathered from users. These software requirements are then analyzed for completeness, errors and dependencies. Then the software requirements are rewritten in a formal and rigid language to make sure that each software requirement is crystal clear and there are no chances of misunderstanding. The representation of software requirements into a rigid and formal language is known as software requirement specification. If any change request comes from the customer/users then a software requirement specification may need to be changed to accommodate the change request. When a change request is made then the project team may need to make changes at many places including software requirement specifications, software design and source code. Managing all these activities is known as requirement management.

Chapter 4 Software Requirement Specifications When all requirements are converted into software requirement specifications and the software requirement process is complete then business analysts can do verification of all the software requirement specifications. They will check if all requirement specifications are complete and error free. Once all requirement specifications are found to be OK then a software design (architecture) can be made based on the software requirement specifications. Transformation of software requirements to software requirement specifications and management of change requests is known as software requirement cycle.

Chapter 4 Software Requirement Specifications A use case depicting an actor, title, scope and goal level

Chapter 4 Software Requirement Specifications One of the best method of creating software requirement specification is to use “use cases”. Use cases depict an actor which interacts with a software product or software feature. The actor could be a user, time or another software system. Each use case contains a title, goal level and scope. Optionally it can also contain a description. If the actor is a user then the use case will describe the input and output on a user screen. If the actor is time then the use case will describe an event which can trigger at specified time. If the actor is another software system then the use case will describe an integration scenario where a message will be delivered from the other software system to the present software system. A title is used to identify a use case. A goal level identifies at what level the use case has been set. A use can have goal levels set at highest, high, user and sub-function. The scope of a use case defines the boundaries under which the use case has been set. For example scope of a use can be set at the system boundary level so that this use case does not describe anything beyond the system boundary (e. g. another software system).

Chapter 4 Software Requirement Specifications Goal levels of requirements

Chapter 4 Software Requirement Specifications Highest level goals for software requirements are set at the system or beyond. For example a use can describe a complete system consisting of a software product as well as other integrated software product. High level goals are set at sub-system level. For example a use can describe customer management which is part of a order management system. User level use cases describe requirements which correspond to a software component. User level requirements are very useful because they help in designing software components. Sub-function level use cases describe requirements which correspond to parts of a software component. For example a use can describe how a user should fill a textbox with constraints mentioned for filling it.