Software Requirement Specification (SRS)

 Software Requirement Specification (SRS)

       Outline

• Review of the requirements engineering process.
• Write requirements and specifications.
• RequisitePro tutorial.
• 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.

2.1  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.

2.2  Writing Requirements

Requirements always need to be correct, unambiguous, complete, consistent, and testable.

2.2.1        Recommendations When Writing Requirements

• Never assume: others do now know what you have in mind.
• Use meaningful words; avoid words like: process, manage, perform, handle, and support.
• State requirements not features:
• Feature: general, tested only for existence.
• Requirement: specific, testable, measurable.
• Avoid:
• Conjunctions: ask yourself whether the requirement should it be split into two requirements.
• Conditionals: if, else, but, except, although.
• Possibilities: may, might, probably, usually.

2.3  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.

2.4  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)

  CASE Tools

RequisitePro is a powerful, easy-to-use requirements management tool that helps teams manage project requirements comprehensively, promotes communication and collaboration among team members, and reduces project risk. It thereby increases the chances of delivering a product that the client wants and does so in a timely manner.

RequisitePro offers the power of a database and Microsoft Word and is integrated with other Rational Suite products.

In-Class Demo

An overview of the basic features of RequisitePro will be presented. In the exercise section you will practice and apply what you have learned in the tutorial. Please refer to lab 4 slides which contain a tutorial on RequisitePro and an overview of the requirements engineering process, and writing requirements and specifications.

      Exercises

a.       Are the following requirements vague? If yes, why? Can you fix them?

o   The feature is responsible for managing connections.

o   The feature allows users to perform administrative functions.

b.      Perform each of the following tasks using RequisitePro:

o   Create a new project.

o   Create a new package.

o   Create and add some requirements within RequisitePro.

o   Create a requirement document.

o   Create a new view.

Deliverables

• You should submit the solutions for exercise 5.a.
• You should show that you have successfully performed all the tasks listed in exercise 5.b.
• Also during the requirement phase of your term project, you should use RequisitePro to manage your requirements.