Software Requirements
- 2. SOFTWARE REQUIREMENTS The software requirements are description of features and functionalities of the target system. 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. REQUIREMENT ENGINEERING • The process to gather the 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.
- 4. REQUIREMENT ENGINEERING PROCESS It is a four step process, which includes – • Feasibility Study • Requirement Gathering • Software Requirement Specification • Software Requirement Validation
- 5. 1) FEASIBILITY PROCESS • When the client approaches the organization for getting the desired product developed, it comes up with rough idea about what all functions the software must perform and which all features are expected from the software. • Referencing to this information, the analysts does a detailed study about whether the desired system and its functionality are feasible to develop. • This feasibility study is focused towards goal of the organization. This study analyzes whether the software product can be practically materialized in terms of implementation, contribution of project to organization, cost constraints and as per values and objectives of the organization. It explores technical aspects of the project and product such as usability, maintainability, productivity and integration ability. • The output of this phase should be a feasibility study report that should contain adequate comments and recommendations for management about whether or not the project should be undertaken.
- 6. 2) REQUIREMENT GATHERING If the feasibility report 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.
- 7. 3) SOFTWARE REQUIREMENT SPECIFICATION • SRS is a document created by system analyst after the requirements are collected from various stakeholders. • SRS defines how the intended software will interact with hardware, external interfaces, speed of operation, response time of system, portability of software across various platforms, maintainability, speed of recovery after crashing, Security, Quality, Limitations etc. • The requirements received from client are written in natural language. It is the responsibility of system analyst to document the requirements in technical language so that they can be comprehended and useful by the software development team.
- 8. A software requirements specification (SRS) is a document that captures complete description about how the system is expected to perform. It is usually signed off at the end of requirements engineering phase.
- 9. SRS should come up with following features: • User Requirements are expressed in natural language. • Technical requirements are expressed in structured language, which is used inside the organization. • Design description should be written in Pseudo code. • Format of Forms and GUI screen prints. • Conditional and mathematical notations for DFDs etc.
- 10. QUALITIES OF SRS • Correct • Unambiguous • Complete • Consistent • Ranked for importance and/or stability • Verifiable • Modifiable • Traceable
- 11. 4) SOFTWARE REQUIREMENT VALIDATION After requirement specifications are developed, the requirements mentioned in this document are validated. User might ask for illegal, impractical solution or experts may interpret the requirements incorrectly. This results in huge increase in cost if not nipped in the bud. Requirements 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 are any ambiguities • If they are complete • If they can be demonstrated
- 13. A software requirement can be of 3 types: • Functional requirements • Non-functional requirements • Domain requirements
- 14. • Functional Requirements: These are the requirements that the end user specifically demands as basic facilities that the system should offer. All these functionalities need to be necessarily incorporated into the system as a part of the contract. These are represented or stated in the form of input to be given to the system, the operation performed and the output expected. They are basically the requirements stated by the user which one can see directly in the final product, unlike the non-functional requirements. • For example, in a hospital management system, a doctor should be able to retrieve the information of his patients. Each high-level functional requirement may involve several interactions or dialogues between the system and the outside world. In order to accurately describe the functional requirements, all scenarios must be enumerated. • There are many ways of expressing functional requirements e.g., natural language, a structured or formatted language with no rigorous syntax and formal specification language with proper syntax.
- 15. Non-functional requirements: These are basically the quality constraints that the system must satisfy according to the project contract. The priority or extent to which these factors are implemented varies from one project to other. They are also called non-behavioral requirements. They basically deal with issues like: • Portability • Security • Maintainability • Reliability • Scalability • Performance • Reusability • Flexibility
- 16. NFR’s are classified into following types: • Interface constraints • Performance constraints: response time, security, storage space, etc. • Operating constraints • Life cycle constraints: mantainability, portability, etc. • Economic constraints The process of specifying non-functional requirements requires the knowledge of the functionality of the system, as well as the knowledge of the context within which the system will operate.
- 17. Domain requirements: Domain requirements are the requirements which are characteristic of a particular category or domain of projects. The basic functions that a system of a specific domain must necessarily exhibit come under this category. For instance, in an academic software that maintains records of a school or college, the functionality of being able to access the list of faculty and list of students of each grade is a domain requirement. These requirements are therefore identified from that domain model and are not user specific.
- 19. • Requirements gathering - The developers discuss with the client and end users and know their expectations from the software. • Organizing Requirements - The developers prioritize and arrange the requirements in order of importance, urgency and convenience. • Negotiation & discussion - If requirements are ambiguous or there are some conflicts in requirements of various stakeholders, if they are, it is then negotiated and discussed with stakeholders. Requirements may then be prioritized and reasonably compromised. • The requirements come from various stakeholders. To remove the ambiguity and conflicts, they are discussed for clarity and correctness. Unrealistic requirements are compromised reasonably. • Documentation - All formal & informal, functional and non-functional requirements are documented and made available for next phase processing.
- 20. REQUIREMENT ELICITATION TECHNIQUES Requirements Elicitation is the process to find out the requirements for an intended software system by communicating with client, end users, system users and others who have a stake in the software system development. There are various ways to discover requirements
- 21. 1) INTERVIEWS Interviews are strong medium to collect requirements. Organization may conduct several types of interviews such as: • Structured (closed) interviews, where every single information to gather is decided in advance, they follow pattern and matter of discussion firmly. • Non-structured (open) interviews, where information to gather is not decided in advance, more flexible and less biased. • Oral interviews • Written interviews • One-to-one interviews which are held between two persons across the table. • Group interviews which are held between groups of participants. They help to uncover any missing requirement as numerous people are involved
- 22. 2) SURVEYS Organization may conduct surveys among various stakeholders by querying about their expectation and requirements from the upcoming system.
- 23. 3) QUESTIONNAIRES A document with pre-defined set of objective questions and respective options is handed over to all stakeholders to answer, which are collected and compiled. A shortcoming of this technique is, if an option for some issue is not mentioned in the questionnaire, the issue might be left unattended.
- 24. 4) TASK ANALYSIS Team of engineers and developers may analyze the operation for which the new system is required. If the client already has some software to perform certain operation, it is studied and requirements of proposed system are collected.
- 25. 5) DOMAIN ANALYSIS Every software falls into some domain category. The expert people in the domain can be a great help to analyze general and specific requirements.
- 26. 6) BRAINSTORMING An informal debate is held among various stakeholders and all their inputs are recorded for further requirements analysis.
- 27. 7) PROTOTYPING Prototyping is building user interface without adding detail functionality for user to interpret the features of intended software product. It helps giving better idea of requirements. If there is no software installed at client’s end for developer’s reference and the client is not aware of its own requirements, the developer creates a prototype based on initially mentioned requirements. The prototype is shown to the client and the feedback is noted. The client feedback serves as an input for requirement gathering.
- 28. 8) OBSERVATIONS Team of experts visit the client’s organization or workplace. They observe the actual working of the existing installed systems. They observe the workflow at client’s end and how execution problems are dealt. The team itself draws some conclusions which aid to form requirements expected from the software.
- 29. SOFTWARE REQUIREMENTS CHARACTERISTICS Gathering software requirements is the foundation of the entire software development project. Hence they must be clear, correct and well-defined.
- 30. A complete Software Requirement Specifications must be: • Clear • Correct • Consistent • Coherent • Comprehensible • Modifiable • Verifiable • Prioritized • Unambiguous • Traceable • Credible source
- 31. REQUIREMENT MANAGEMENT • Requirements management is the process of collecting, analyzing, refining, and prioritizing product requirements and then planning for their delivery. The purpose of requirements management is to ensure that the organization validates and meets the needs of its customers and external and internal stakeholders. • Requirements management involves communication between the project team members and stakeholders, and adjustment to requirements changes throughout the course of the project. To prevent one class of requirements from overriding another, constant communication among members of the development team is critical. • Requirements management does not end with product release. From that point on, the data coming in about the application’s acceptability is gathered and fed into the Investigation phase of the next generation or release. Thus the process begins again.
- 32. What is requirements management? A requirement is a defined capability to which the results of certain work (in this case software development) should meet. It is a continuous process throughout the lifecycle of a product and requirements can be generated by many stakeholders including: customers, partners, sales, support, management, engineering, operations, and of course product management. When requirements are being properly curated and managed there is clear and consistent communication between the product team and engineering members and any needed changes are broadly shared with all stakeholders