1. Requirements Engineering Lesson 2

2. Terminologies:  Software Acquisition is where requirement engineering significantly meets business strategy.  Software Requirements are description of features and functionalities of the target system.  Requirements are description of the services that a software must provide and the constraints under which it must operate.  Requirements convey the expectations of users from the software product. The requirements can be obvious or hidden, known or unknown, expected or unexpected from client’s point of view.

3. Types of Requirements  User requirements  Statements in natural language plus diagrams of the services that the systems provides and its operational constraints.  Written for customers  System requirements  A structured document setting out detailed descriptions of the system services  Written as a contract between client and contractor  Software Specifications  A detailed description which can serve as a basis for a design or implementation  Written for developers

4. Functional and non- functional requirements

5. Functional Requirements  Statements of services that the system should provide, how the system should react to particular inputs and how the system should behave in particular situations  Describe functionality or system services  Depend on the type of software, expected users and the and the type of system where the software is used.  Functional user requirements may be high-level statements of what the system should do; it should describe the system services in detail.

6. Functional Requirements Examples:  The user should be able to search either all of the initial set of databases or select a subset from it.  The system shall provide appropriate viewers for the user to read documents in the document store.  Every order shall allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the account’s permanent storage area.

7. Non-functional Requirements  Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, among others.  It can be categorized as product requirements, organisational requirements, and external requirements.

8. Non-functional Requirements  Product Requirements  Requirements which specify that the delivered product must behave in a particular way  Portability, reliability, usability, efficiency – space & performance  Organisational Requirements  Requirements which are a consequence of organisational policies and procedures  Delivery, implementation and standards

9. Non-functional Requirements  External Requirements  Requirements which arises from factors which are external to the system and its development process  Ethical, interoperability, legislative (safety & privacy)

10. Requirement Engineering  The process to gather software requirements from client, analyze and document them is known as Requirement Engineering  The goal of requirement engineering is to develop and maintain sophisticated and descriptive ‘System Requirements Specification’ document.

11. Requirement Engineering Process 1. Feasibility Study 2. Requirements Gathering 3. Software Requirement Specification 4. Software Requirement Validation

12. 1. Feasibility Study  Feasible – possible, achievable, practical. 1. When the client approaches the organizaiton for getting the desired product, 2. the analysts does a detailed study whether the system and its functionality are feasible to develop.  FS is focused towards goal of the organization. It also explores technical aspects of the project and product such as usability, maintainability, productivity and integration ability.

13. 2. Requirement Gathering  If the feasibility is positive towards undertaking the project.  Next phase starts with gathering requirements from the user.  Analysts and engineers communicate with the client and end-users to know their ideas on what the software should provide and which features they want the software to include.

14. 3. Software Requirement Specification  SRS is a document created by system analysts after the requirements are collected from various stakeholders.  The requirements received from a client are written in natural language.  It is the responsibility of system analyst to document the requirements in technical language so that they can comprehend and useful by the software development team.

15. SRS should come up with following features: 1. User Requirements are expressed in natural language. 2. Technical requirements are expressed in structured language, which is used inside the organization. 3. Design description should be written in pseudo code 4. Format forms and GUI screens prints 5. Conditional and mathematical notations for DFDs etc.

16. 4. Software Requirement Validation  After SRS are developed, the requirements mentioned in this document are validated.  User might ask for illegal, impractical solutions or experts may interpret the requirements incorrectly. – Costly.  It can be checked against following conditions.  If they can be practically implemented  If they are valid and as per functionality and domain of software  If there any ambiguities (doubts)  If they are complete  If they can be demonstrated

18. Next topic  Requirement Elicitation Process  Techniques  Characteristics