Handbook of Computer Science(cs) and IT

Software Requirements

Software requirement is a process to understand the exact requirements of the customer and to document them properly. The hardest part of building a software system is deciding precisely what to build.

 

Analysis and Specifications

• Requirements describe the ‘what’ of a system not the ‘how’.
• Requirements engineering produces one large document, contains a description of what the system will do.

 

.

 

 

Requirement Elicitation

This is also known as gathering of requirements. Here, requirements are identified with the help of customer and existing system processes.

available.

There are following methods that can be used in requirement elicitation

• Interviews First step to understand the problem statement of customer e., meeting with customer.
• Brainstorming Sessions It is a kind of group discussion which ma_y lead to new ideas quickly and help to promote creative thinking.
• Facilitated Application Specification Technique (FAST) The objecti_ve of FAST approach is to bridge the expectation gap, a difference between what developers think they are supposed to build and what custome_rs think they are going to get.
• The Use Case Approach This approach uses a combination of text and pictures in order to improve the understanding of requirements.

Use case diagrams are graphical representations that may b_e decomposed into further levels of abstraction.

 

Design of the Use Case Approach

The following components are used for the design of the use case approach

Actor or external agent lies outsides the system model but interacts with it in some way. An actor may be a person, machine or an information system.

Use case is initiated by a user with a particular goal in mind and competes
successfully when that goal is satisfied. It describes the sequence of
interactions between actors and the system necessary to deliver services

that satisfies the goal.

Requirement Analysis

Requirement analysis allows the system analyst to refine the software
allocation and build conceptual models of the data, functional and

behavioural domains that will be treated by software.

 

Data Modeling

• Define data objects attributes and relationship.
• We use E-R diagrams for this purpose,

pavioural Modeling

• Finding out different states of the system,
• Specifying events that cause the system to change state.
• We use state transition diagrams for behavioural modeling.

Function Modeling

• Identify functions that transform data objects .
• Indicate how data flows through system.
• Represent producers and consumers of data.

 

Requirement Documentation

Requirement document is the way to represent requirements in a consistent format. Requirement document is called SRS i.e., Software Requirements Specification. The SRS should be correct, unambiguous, complete, consistent, verifiable, modifiable, traceable.

–Key Points —–

• For function modeling, we use Data Flow Diagrams (DFDs). DFD shows the flow of data through a system.
• The requirement review process is carried out to improve the quality of the SRS.
• The requirement review process may also be called as requirements verification.

For maximum benefits, review and verification should not be treated as a discrete activity to be done only at the end of preparation of SRS. It should be treated as continuous activity that is incorporated into the elicitation, analyst and documentation.

 

Requirement Validation

After the completions of SRS document, we may like to check the documents for

• Completeness and consistency
• Conformance to standards
• Requirements conflicts
• Technical errors
• Ambiguous requirements

 

 

 

Validation Process with Inputs and Outputs

The objective of requirements validation is to certify that the SRS is an acceptable document of the system to be implemented.