01-03-2013, 11:36 AM
Software Requirement Specification (SRS)
Software Requirement.docx (Size: 22.82 KB / Downloads: 19)
Outline
• Review of the requirements engineering process.
• Write requirements and specifications.
• Software Requirement Specification (SRS).
Background
A requirement is a statement of a behavior or attribute that a system must possess for the system to be acceptable to a stakeholder.
Software Requirement Specification (SRS) is a document that describes the requirements of a computer system from the user's point of view. An SRS document specifies:
• The required behavior of a system in terms of: input data, required processing, output data, operational scenarios and interfaces.
• The attributes of a system including: performance, security, maintainability, reliability, availability, safety requirements and design constraints.
Requirements management is a systematic approach to eliciting, organizing and documenting the requirements of a system. It is a process that establishes and maintains agreement between the customer and the project team on the changing requirements of a system.
Requirements management is important because, by organizing and tracking the requirements and managing the requirement changes, you improve the chances of completing the project on time and under budget. Poor change management is a key cause of project failure.
Requirements Engineering Process
Requirements engineering process consists of four phases:
• Requirements elicitation: getting the customers to state exactly what the requirements are.
• Requirements analysis: making qualitative judgments and checking for consistency and feasibility of requirements.
• Requirements validation: demonstrating that the requirements define the system that the customer really wants.
• Requirements management: the process of managing changing requirements during the requirements engineering process and system development, and identifying missing and extra requirements.
Writing Specifications
Specification is a description of operations and attributes of a system. It can be a document, set of documents, a database of design information, a prototype, diagrams or any combination of these things.
Specifications are different from requirements: specifications are sufficiently complete ─ not only what stakeholders say they want; usually, they have no conflicts; they describe the system as it will be built and resolve any conflicting requirements.
Creating specifications is important. However, you may not create specifications if:
• You are using a very incremental development process (small changes).
• You are building research or proof of concept projects.
• You rebuilding very small projects.
• It is not cheaper or faster than building the product.
Software Requirement Specification (SRS)
Remember that there is no “Perfect SRS”. However, SRS should be:
• Correct: each requirement represents something required by the target system.
• Unambiguous: every requirement in SRS has only one interpretation
• Complete: everything the target system should do is included in SRS (no sections are marked TBD-to be determined).
• Verifiable: there exists some finite process with which a person/machine can check that the actual as-built software product meets the requirements.
• Consistent in behavior and terms.
• Understandable by customers.
• Modifiable: changes can be made easily, completely and consistently.
• Design independent: doesn't imply specific software architecture or algorithm.
• Concise: shorter is better.
• Organized: requirements in SRS are easy to locate; related requirements are together.
• Traceable: each requirement is able to be referenced for later use (by the using paragraph numbers, one requirement in each paragraph, or by using convention for indication requirements)