Unit 3: �Requirements Engineering

Prepared by

Er. Binod Kumar Rajbhar

​

​

www.notedinsights.com

​

3.1. Functional and Non-Functional Requirements

• Requirements analysis is very critical process that enables the success of a system or software project to be assessed.
• Requirements are generally split into two types: Functional and Non-functional requirements.
• Functional Requirements:
• These are the requirements that the end user specifically demands as basic facilities that the system should offer.
• All these functionalities need to be necessarily incorporated into the system as a part of the contract.
• These are represented or stated in the form of input to be given to the system, the operation performed and the output expected.
• They are basically the requirements stated by the user which one can see directly in the final product, unlike the non-functional requirements

​

• Non-functional requirements:
• These are basically the quality constraints that the system must satisfy according to the project contract.
• The priority or extent to which these factors are implemented varies from one project to other.
• They are also called non-behavioral requirements.
• They basically deal with issues like:
• Portability
• Security
• Maintainability
• Reliability
• Scalability
• Performance
• Reusability
• Flexibility

​

Differences between Functional and Non Functional Requirements

Functional

• A functional requirement defines a system or its component.
• It specifies “What should the software system do?”
• Functional requirement is specified by User.
• It is mandatory.
• It is captured in use case
• Defined at a component level.
• Helps you verify the functionality of the software.

​

Functional Requirements

• A non-functional requirement defines the quality attribute of a software system
• It places constraints on “How should the software system fulfill the functional requirements?”
• Non-functional requirement is specified by technical peoples e.g. Architect, Technical leaders and software developers.
• It is not mandatory.
• It is captured as a quality attribute.
• Applied to a system as a whole.

Differences between Functional and Non Functional Requirements

Functional

​

• Helps you verify the functionality of the software.
• Functional Testing like System, Integration, End to End, API testing, etc are done.
• Usually easy to define.
• Example1) Authentication of user whenever he/she logs into the system.�2) System shutdown in case of a cyber attack.�3) A Verification email is sent to user whenever he/she registers for the first time on some software system.

​

Functional Requirements

​

• Helps you to verify the performance of the software.
• Non-Functional Testing like Performance, Stress, Usability, Security testing, etc are done.
• Usually more difficult to define.
• Example1) Emails should be sent with a latency of no greater than 12 hours from such an activity.�2) The processing of each request should be done within 10 seconds�3) The site should load in 3 seconds when the number of simultaneous users are > 10000

​

Requirement Engineering�

• Requirements engineering (RE) refers to the process of defining, documenting, and maintaining requirements in the engineering design process.
• Requirement engineering provides the appropriate mechanism to understand what the customer desires, analyzing the need, and assessing feasibility, negotiating a reasonable solution, specifying the solution clearly, validating the specifications and managing the requirements as they are transformed into a working system.
• Thus, requirement engineering is the disciplined application of proven principles, methods, tools, and notation to describe a proposed system's intended behavior and its associated constraints.

Requirement Engineering Process�

It is a four-step process, which includes -

1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
5. Software Requirement Management

​

Requirement Engineering Process�

1. Feasibility Study:�

• The objective behind the feasibility study is to create the reasons for developing the software that is acceptable to users, flexible to change and conformable to established standards.

Types of Feasibility:

1. Technical Feasibility - Technical feasibility evaluates the current technologies, which are needed to accomplish customer requirements within the time and budget.
2. Operational Feasibility - Operational feasibility assesses the range in which the required software performs a series of levels to solve business problems and customer requirements.
3. Economic Feasibility - Economic feasibility decides whether the necessary software can generate financial profits for an organization.

​

2. Requirement Elicitation and Analysis: �

• This is also known as the gathering of requirements. Here, requirements are identified with the help of customers and existing systems processes, if available.
• Analysis of requirements starts with requirement elicitation. The requirements are analyzed to identify inconsistencies, defects, omission, etc. We describe requirements in terms of relationships and also resolve conflicts if any.
• Problems of Elicitation and Analysis:
• Getting all, and only, the right people involved.
• Stakeholders often don't know what they want
• Stakeholders express requirements in their terms.
• Stakeholders may have conflicting requirements.
• Requirement change during the analysis process.
• Organizational and political factors may influence system requirements.

​

3. Software Requirement Specification: �

• Software requirement specification is a kind of document which is created by a software analyst after the requirements collected from the various sources - the requirement received by the customer written in ordinary language.
• It is the job of the analyst to write the requirement in technical language so that they can be understood and beneficial by the development team.
• The models used at this stage include ER diagrams, data flow diagrams (DFDs), function decomposition diagrams (FDDs), data dictionaries, etc.
• 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.

4. Software Requirement Validation: �

• After requirement specifications developed, the requirements discussed in this document are validated.
• The user might demand illegal, impossible solution or experts may misinterpret the needs.
• Requirements can be the check against the following conditions -
• If they can practically implement
• If they are correct and as per the functionality and specially of software
• If there are any ambiguities
• If they are full
• If they can describe

​

Requirements Validation Techniques

• Requirements reviews/inspections: systematic manual analysis of the requirements.
• Prototyping: Using an executable model of the system to check requirements.
• Test-case generation: Developing tests for requirements to check testability.
• Automated consistency analysis: checking for the consistency of structured requirements descriptions.

​

Software Requirement Management: �

• Requirement management is the process of managing changing requirements during the requirements engineering process and system development.
• New requirements emerge during the process as business needs a change, and a better understanding of the system is developed.
• The priority of requirements from different viewpoints changes during development process.
• The business and technical environment of the system changes during the development.

​

3.3 Requirements Elicitation�

• Requirements elicitation is the process of gathering and defining the requirements for a software system.
• The goal of requirements elicitation is to ensure that the software development process is based on a clear and comprehensive understanding of the customer’s needs and requirements.
• Requirements elicitation involves the identification, collection, analysis, and refinement of the requirements for a software system.
• It is a critical part of the software development life cycle and is typically performed at the beginning of the project.
• Requirements elicitation involves stakeholders from different areas of the organization, including business owners, end-users, and technical experts.
• The output of the requirements elicitation process is a set of clear, concise, and well-defined requirements that serve as the basis for the design and development of the software system.

Requirements elicitation Activities:

• Requirements elicitation includes the subsequent activities.
• Few of them are listed below – 
• Knowledge of the overall area where the systems is applied.
• The details of the precise customer problem where the system is going to be applied must be understood.
• Interaction of system with external requirements.
• Detailed investigation of user needs.
• Define the constraints for system development.

​

Requirements elicitation Methods:

• There are a number of requirements elicitation methods. Few of them are listed below – 
• Interviews
• Brainstorming Sessions
• Facilitated Application Specification Technique (FAST)
• Quality Function Deployment (QFD)
• Use Case Approach

The success of an elicitation technique used depends on the maturity of the analyst, developers, users, and the customer involved. 

​

1. Interviews: 

• Objective of conducting an interview is to understand the customer’s expectations from the software.
• It is impossible to interview every stakeholder hence representatives from groups are selected based on their expertise and credibility.
• Interviews maybe be open-ended or structured.
• In open-ended interviews there is no pre-set agenda. Context free questions may be asked to understand the problem.

In structured interview, agenda of fairly open questions is prepared. Sometimes a proper questionnaire is designed for the interview.

2. Brainstorming Sessions: 

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

​

3. Facilitated Application Specification Technique: 

• Its objective is to bridge the expectation gap – the difference between what the developers think they are supposed to build and what customers think they are going to get.
• A team-oriented approach is developed for requirements gathering. Each attendee is asked to make a list of objects that are-
• Part of the environment that surrounds the system
• Produced by the system
• Used by the system
• Each participant prepares his/her list, different lists are then combined, redundant entries are eliminated, team is divided into smaller sub-teams to develop mini-specifications and finally a draft of specifications is written down using all the inputs from the meeting.

4. Quality Function Deployment: 

• In this technique customer satisfaction is of prime concern, hence it emphasizes on the requirements which are valuable to the customer.
• 3 types of requirements are identified –
• Normal requirements –
• In this the objective and goals of the proposed software are discussed with the customer. Example – normal requirements for a result management system may be entry of marks, calculation of results, etc
• Expected requirements –
• These requirements are so obvious that the customer need not explicitly state them. Example – protection from unauthorized access.
• Exciting requirements –
• It includes features that are beyond customer’s expectations and prove to be very satisfying when present. Example – when unauthorized access is detected, it should backup and shutdown all processes.

• The major steps involved in this procedure are –
• Identify all the stakeholders, eg. Users, developers, customers etc
• List out all requirements from customer.
• A value indicating degree of importance is assigned to each requirement.
• In the end the final list of requirements is categorized as –
• It is possible to achieve
• It should be deferred and the reason for it
• It is impossible to achieve and should be dropped off

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

Features of requirements elicitation:�

1. Stakeholder engagement: Requirements elicitation involves engaging with stakeholders such as customers, end-users, project sponsors, and subject matter experts to understand their needs and requirements.
2. Gathering information: Requirements elicitation involves gathering information about the system to be developed, the business processes it will support, and the end-users who will be using it.
3. Requirement prioritization: Requirements elicitation involves prioritizing requirements based on their importance to the project’s success.
4. Requirements documentation: Requirements elicitation involves documenting the requirements in a clear and concise manner so that they can be easily understood and communicated to the development team.
5. Validation and verification: Requirements elicitation involves validating and verifying the requirements with the stakeholders to ensure that they accurately represent their needs and requirements.
6. Iterative process: Requirements elicitation is an iterative process that involves continuously refining and updating the requirements based on feedback from stakeholders.
7. Communication and collaboration: Requirements elicitation involves effective communication and collaboration with stakeholders, project team members, and other relevant parties to ensure that the requirements are clearly understood and implemented.
8. Flexibility: Requirements elicitation requires flexibility to adapt to changing requirements, stakeholder needs, and project constraints.

​

Advantages of Requirements Elicitation:�

• Helps to clarify and refine customer requirements.
• Improves communication and collaboration between stakeholders.
• Increases the chances of developing a software system that meets customer needs.
• Avoids misunderstandings and helps to manage expectations.
• Supports the identification of potential risks and problems early in the development cycle.
• Facilitates the development of a comprehensive and accurate project plan.
• Increases user and stakeholder confidence in the software development process.
• Supports the identification of new business opportunities and revenue streams.

​

Disadvantages of Requirements Elicitation:�

• Can be time-consuming and expensive.
• Requires specialized skills and expertise.
• May be impacted by changing business needs and requirements.
• Can be impacted by political and organizational factors.
• Can result in a lack of buy-in and commitment from stakeholders.
• Can be impacted by conflicting priorities and competing interests.
• May result in incomplete or inaccurate requirements if not properly managed.
• Can lead to increased development costs and decreased efficiency if requirements are not well-defined.

​

3.4 Requirements Specification�

• Requirements specification is a critical part of the Requirements Engineering process.
• It is the third phase, after Requirements Capture and Analysis.
• The goal is to create a document, or Requirements Specification, with the corresponding level of detail.
• This document will contain all requirements that are to be imposed on the design and verification of the product.
• It will also contain other related information necessary for the design, verification, and maintenance of the product.

What is Requirements Specification?�

• Requirement specification, also known as documentation, is a process of jotting down all the system and user requirements in the form of a document.
• These requirements must be clear, complete, comprehensive, and consistent. 
• During the capturing activity, we gather all the requirements from various sources.
• During the analysis and negotiation activities, we analyze and understand those requirements.
• Now, we must prepare a formal document explaining those requirements. That is what the requirement specification is.
• To be precise, it is the process of documenting all the user and system needs and constraints in a clear and accurate manner.

​

���

What is a System Requirement?

• System requirements can be called the expanded version of the user requirements.
• System requirements act as the commencement point for any new system design.
• These requirements are a detailed description of the user requirements the system must satisfy.

What is a User Requirement?

• User requirement is a combination of functional and non-functional requirements.
• These user requirements must be designed in such a way that they are easily understandable by users who do not have any sort of technical knowledge.
• Hence, they must be written in natural language using simple tables, forms, and diagrams.
• Also, make sure the document does not have details on system design, software, or formal notations. 

​

What are Functional and Non-Functional Requirements?�

• Functional requirements, as the name suggests, describe the functions of the system to be designed.
• It is a description of what the system will be and how it will function to satisfy user needs.
• They provide a clear description of how the system is supposed to respond to a particular command, the features, and what the users expect. 
• Non-functional requirements explain the limitations and constraints of the system to be designed.
• These requirements do not have any impact on the functionality of the application.
• Furthermore, there is a common practice of sub-classifying the non-functional requirements into various categories like

​

• User Interface
• Reliability 
• Security
• Performance
• Maintenance
• Standards 

​

• Non-functional requirements are as important as functional requirements are.
• If functional requirements specify what a system should do, non-functional requirements describe how the system will do it.
• For example, the new application shall provide us with the final list of all connected users. That is a part of functional requirements.
• If the requirement says that the system would only work on a Windows and a Linux system, that would be a part of non-functional requirements. 
• The only difference between the two is that the system can not function without satisfying all the functional requirements.
• On the other hand, the system will give you the desired outcome even when it does not satisfy the non-functional requirements.

​

What are The Benefits of Having a Requirements Specification?�

There are many benefits of having a requirements specification. Some of them are listed below:

• Helps to ensure that all stakeholders have a common understanding of the system that is to be developed. This avoids any misunderstanding during later stages of development.
• Serves as a reference point for all stakeholders during the development process.
• Helps to identify any gaps in the requirements at an early stage.
• Reduces the overall cost and time of development as it avoids rework due to changes in requirements.

​

Requirements Validation�

• Requirements validation is the process of checking that requirements actually define the system that the customer really wants.
• It overlaps with analysis as it is concerned with finding problems with the requirements.
• Requirements validation is important because errors in a requirements document can lead to extensive rework costs when these problems are discovered during development or after the system is in service The cost of fixing a requirements problem by making a system change is usually much greater than repairing design or coding errors.
• The reason for this is that a change to the requirements usually means that the system design and implementation must also be changed. Furthermore the system must then be re-tested.

​

During the requirements validation process, different types of checks should be carried out on the requirements in the requirements document. These checks include:

• Validity checks. A user may think that a system is needed to perform certain functions. However, further thought and analysis may identify additional or different functions that are required..
• Consistency checks. Requirements in the document should not conflict. That is, there should not

be contradictory constraints or different descriptions of the same system function.

• Completeness checks. The requirements document should include requirements that define all functions and the constraints intended by the system user.
• Realism checks. Using knowledge of existing technology, the requirements should be checked to ensure that they can actually be implemented. These checks should also take account of the budget and schedule for the system development.
• Verifiability. To reduce the potential for dispute between customer and contractor, system

requirements should always be written so that they are verifiable. This means that you should be able to write a set of tests that can demonstrate that the delivered system meets each specified requirement.

​

There are a number of requirements validation techniques that can be used individually or in conjunction with one another:

1. Requirements reviews. The requirements are analyzed systematically by a team of reviewers who check for errors and inconsistencies.
2. Prototyping. In this approach to validation, an executable model of the system in question is demonstrated to end-users and customers. They can experiment with this model to see if it meets their real needs.
3. Test-case generation. Requirements should be testable. If the tests for the requirements are devised as part of the validation process, this often reveals requirements problems. If a test is difficult or impossible to design, this usually means that the requirements will be difficult to implement and should be reconsidered. Developing tests from the user requirements before any code is written is an integral part of extreme programming.

​