4.1 Requirement engineering
4.2 Requirement elicitation
4.2.1 Interviews
4.2.2 Brainstorming series
4.2.3 Use case approach
4.3 Requirement analysis
4.3.1. Data flow diagram
4.3.2 Data dictionary
4.3.3 Entity-Relationship diagram
4.3.4 Software prototyping
4.4 Requirement documentation
4.4.1 Nature of SRS
4.4.2 Characteristics of a good SRS
4.4.3 Organization of SRS
Requirement Engineering
Requirement Engineering is the process of defining, documenting and maintaining the requirements. It is a process of gathering and defining service provided by the system. Requirements Engineering Process consists of the following main activities:
- Requirements elicitation
- Requirements specification
- Requirements verification and validation
- Requirements management
- Requirements elicitation is perhaps the most difficult, most error-prone and most communication intensive software development. It can be successful only through an effective customer-developer partnership. It is needed to know what the users really need.
There are a number of requirements elicitation methods. Few of them are listed below
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
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.
- Brainstorming
- An informal debate is held among various stakeholders and all their inputs are recorded for further requirements analysis.
- It is a group technique
- It is intended to generate lots of new ideas hence providing a platform to share views
- A highly trained facilitator is required to handle group bias and group conflicts.
- Every idea is documented so that everyone can see it.
- Finally, a document is prepared which consists of the list of requirements and their priority if possible.
Use Case Approach:
This technique combines text and pictures to provide a better understanding of the requirements. The use cases describe the ‘what’, of a system and not ‘how’. Hence, they only give a functional view of the system. The components of the use case design includes three major things – Actor, Use cases, use case diagram.
Actor –
It is the external agent that lies outside the system but interacts with it in some way. An actor maybe a person, machine etc. It is represented as a stick figure. Actors can be primary actors or secondary actors.
- Primary actors – It requires assistance from the system to achieve a goal.
- Secondary actor – It is an actor from which the system needs assistance.
Use cases –
They describe the sequence of interactions between actors and the system. They capture who(actors) do what(interaction) with the system. A complete set of use cases specifies all possible ways to use the system.
- Use case diagram –
A use case diagram graphically represents what happens when an actor interacts with a system. It captures the functional aspect of the system.
A stick figure is used to represent an actor.
An oval is used to represent a use case.
A line is used to represent a relationship between an actor and a use case.
Requirement analysis
Requirement Analysis, also known as Requirement Engineering, is the process of defining user expectations for a new software being built or modified.
Some of the technique for requirement analysis are:
Data Flow Diagrams:
Data Flow Diagrams (DFDs) are used widely for modeling the requirements. DFD shows the flow of data through a system. The system may be a company, an organization, a set of procedures, a computer hardware system, a software system, or any combination of the preceding. The DFD is also known as a data flow graph or bubble chart.
Data Dictionaries: Data Dictionaries are simply repositories to store information about all data items defined in DFDs. At the requirements stage, the data dictionary should at least define customer data items, to ensure that the customer and developers use the same definition and terminologies.
Entity-Relationship Diagrams:
Another tool for requirement specification is the entity-relationship diagram, often called an "E-R diagram." It is a detailed logical representation of the data for the organization and uses three main constructs i.e. data entities, relationships, and their associated attributes.
Requirement documentation
A Software Requirements Specification (SRS) is a document that describes the nature of a project, software or application. In simple words, SRS document is a manual of a project provided it is prepared before you kick-start a project/application.
Nature of Software Requirement Specification (SRS):
The basic issues that SRS writer shall address are the following:
1. Functionality: What the software is supposed to do?
2. External Interfaces: How does the software interact with people, system's hardware, other hardware and other software?
3. Performance: What is the speed, availability, response time, recovery time etc.
4. Attributes: What are the considerations for portability, correctness, maintainability, security, reliability etc.
5. Design Constraints Imposed on an Implementation: Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environment etc.
Characteristics of good SRS
Following are the features of a good SRS document:
1. Correctness: User review is used to provide the accuracy of requirements stated in the SRS. SRS is said to be perfect if it covers all the needs that are truly expected from the system.
2. Completeness: Completeness of SRS indicates every sense of completion including the numbering of all the pages, resolving the to be determined parts to as much extent as possible as well as covering all the functional and non-functional requirements properly.
3. Consistency: Requirements in SRS are said to be consistent if there are no conflicts between any set of requirements. Examples of conflict include differences in terminologies used at separate places, logical conflicts like time period of report generation, etc.
4. Unambiguousness: SRS is unambiguous when every fixed requirement has only one interpretation. This suggests that each element is uniquely interpreted. In case there is a method used with multiple definitions, the requirements report should determine the implications in the SRS so that it is clear and simple to understand.
5. Ranking for importance and stability: The SRS is ranked for importance and stability if each requirement in it has an identifier to indicate either the significance or stability of that particular requirement.
6. Modifiability: SRS should be made as modifiable as likely and should be capable of quickly obtain changes to the system to some extent. Modifications should be perfectly indexed and cross-referenced.
7. Verifiability: SRS is correct when the specified requirements can be verified with a cost-effective system to check whether the final software meets those requirements. The requirements are verified with the help of reviews.
8. Traceability : The SRS is traceable if the origin of each of the requirements is clear and if it facilitates the referencing of each condition in future development or enhancement documentation.
9. Design Independence: There should be an option to select from multiple design alternatives for the final system. More specifically, the SRS should not contain any implementation details.
10. Testability: An SRS should be written in such a method that it is simple to generate test cases and test plans from the report.
11. Understandable by the customer: An end user may be an expert in his/her explicit domain but might not be trained in computer science. Hence, the purpose of formal notations and symbols should be avoided too as much extent as possible. The language should be kept simple and clear.
Tags:
Software_Engineering