Loading in 2 Seconds...
Loading in 2 Seconds...
Software Requirement Analysis & Software Requirement Specification. Prepared By: Shrestha Roshan. Requirements Engineering. Requirements engineering = gathering, negotiating, analyzing, and documenting requirements
Requirements engineering = gathering, negotiating, analyzing, and documenting requirements
The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.
The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process.
A classification of requirements:
User requirements: higher level description of services requested and constraints imposed
System requirements: a more detailed, structured description of services and constraints. Usually included in the contract between the developer and the client
An even more detailed description of requirements can be provided in a software design specification (closer to implementation)
User Requirement Definition
We learn what the user needs are.
We propose how to address them by defining system requirements.
We specify what we are going to build in system requirements.
We describe how to address this by designing the system.
The system design says what we are going to build.
The software requirements tell how we will build part of the system in software.
The software requirements tell what we will build in software.
The software design how we are going to structure the software.
The software design tells what software structure we will build.
The code tells how this will be implemented.
The software requirements specification (SRS) represents a complete description of the behavior of the software to be developed.
The SRS includes:
A set of use cases that describe all of the interactions that the users will have with the software.
All of the functional requirements necessary to define the internal workings of the software: calculations, technical details, data manipulation and processing, and other specific functionality that shows how the use cases are to be satisfied
Nonfunctional requirements, which impose constraints on the design or implementation (such as performance requirements, quality standards or design constraints).
Lack of clarity
Precision is difficult without making the document difficult to read.
Functional and non-functional requirements tend to be mixed-up.
Several different requirements may be expressed together.
Problems arise when requirements are not precisely stated.
Ambiguous requirements may be interpreted in different ways by developers and users.
Consider the term ‘appropriate viewers’
User intention - special purpose viewer for each different document type;
Developer interpretation - Provide a text viewer that shows the contents of the document.
In principle, requirements should be both complete and consistent.
They should include descriptions of all facilities required.
There should be no conflicts or contradictions in the descriptions of the system facilities.
In practice, it is impossible to produce a complete and consistent requirements document.
There is no perfect software, perfect system, perfect language or perfect code block that’s the whole reason “exceptions” were introduced and catching them made it into one of best practices.-Unknown