MODULE 2

Different types of requirements

A software requirement can be of 3 types:
● Functional requirements
● Non-functional requirements
● Domain 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. For example, in a hospital management system, a doctor should be
able to retrieve the information of his patients. Each high-level functional
requirement may involve several interactions or dialogues between the system and
the outside world. In order to accurately describe the functional requirements, all
scenarios must be enumerated.

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 nonbehavioral requirements.
They basically deal with issues like:
● Portability
● Security
● Maintainability
● Reliability
● Scalability
● Performance
● Reusability
● Flexibility
The process of specifying non-functional requirements requires the knowledge of
the functionality of the system, as well as the knowledge of the context within
which the system will operate.
Domain requirements:
Domain requirements are the requirements which are characteristic of a particular
category or domain of projects. The basic functions that a system of a specific
domain must necessarily exhibit come under this category. For instance, in an
academic software that maintains records of a school or college, the functionality
of being able to access the list of faculty and list of students of each grade is a
domain requirement. These requirements are therefore identified from that domain
model and are not user specific.
Seven distinct requirements engineering functions.

The broad spectrum of tasks and techniques that lead to an

understanding of requirements is called requirements engineering. It
encompasses seven distinct tasks: inception, elicitation, elaboration,
negotiation, specification, validation, and management. It is important
to note that some of these tasks occur in parallel and all are adapted to
the needs of the project.
 1. Inception
● Inception is a task where the requirement engineering asks a set of questions
to establish a software process.
● In this task, it understands the problem and evaluates with the proper
solution.
● It collaborates with the relationship between the customer and the
developer.
● The developer and customer decide the overall scope and the nature of the
question.

2. Elicitation
Elicitation means to find the requirements from anybody.
The requirements are difficult because the following problems occur in
elicitation.

Problem of scope: The customer give the unnecessary technical detail rather than
clarity of the overall system objective.

Problem of understanding: Poor understanding between the customer and the

developer regarding various aspect of the project like capability, limitation of the
computing environment.

Problem of volatility: In this problem, the requirements change from time to time
and it is difficult while developing the project.

3. Elaboration
● In this task, the information taken from user during inception and
elaboration and are expanded and refined in elaboration.
● Its main task is developing pure model of software using functions, feature
and constraints of a software.

4. Negotiation
● In negotiation task, a software engineer decides the how will the project be
achieved with limited business resources.
 ● To create rough guesses of development and access the impact of the
requirement on the project cost and delivery time.

5. Specification
● In this task, the requirement engineer constructs a final work product.
● The work product is in the form of software requirement specification.
● In this task, formalize the requirement of the proposed software such as
informative, functional and behavioral.
● The requirements are formalize in both graphical and textual formats.

6. Validation
● The work product is built as an output of the requirement engineering and
that is accessed for the quality through a validation step.
● The formal technical reviews from the software engineer, customer and
other stakeholders helps for the primary requirements validation
mechanism.

7. Requirement management
● It is a set of activities that help the project team to identify, control and track
the requirements and changes can be made to the requirements at any time
of the ongoing project.
● These tasks start with the identification and assign a unique identifier to
each of the requirement.
● After finalizing the requirement traceability table is developed.
● The examples of traceability table are the features, sources, dependencies,
subsystems
and interface of the requirement.

Eliciting requirments
Requirements elicitation (also called requirements gathering) combines
elements of problem solving, elaboration, negotiation, and specification. In
order to encourage
a collaborative, team-oriented approach to requirements gathering,
stakeholders work together to identify the problem, propose elements of
the solution, negotiate different approaches and specify a preliminary set
of solution requirements.
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.

Surveys
Organization may conduct surveys among various stakeholders by querying
about their expectation and requirements from the upcoming system.

Questionnaires
A document with pre-defined set of objective questions and respective options
is handed over to all stakeholders to answer, which are collected and compiled.
A shortcoming of this technique is, if an option for some issue is not
mentioned in the questionnaire, the issue might be left unattended.

Task analysis
Team of engineers and developers may analyze the operation for which the new
system is required. If the client already has some software to perform certain
operation, it is studied and requirements of proposed system are collected.

Domain Analysis
Every software falls into some domain category. The expert people in the
domain can be a great help to analyze general and specific requirements.

Brainstorming
 An informal debate is held among various stakeholders and all their inputs are
recorded for further requirements analysis.

Prototyping
Prototyping is building user interface without adding detail functionality for user
to interpret the features of intended software product. It helps giving better idea
of requirements. If there is no software installed at client’s end for developer’s
reference and the client is not aware of its own requirements, the developer
creates a prototype based on initially mentioned requirements. The prototype is
shown to the client and the feedback is noted. The client feedback serves as an
input for requirement gathering.

Observation
Team of experts visit the client’s organization or workplace. They observe the
actual working of the existing installed systems. They observe the workflow at
client’s end and how execution problems are dealt. The team itself draws some
conclusions which aid to form requirements expected from the software.

Developping Use cases

The use case diagram is one of the diagrams in UML and SysML , the UML
extension for system modeling. It is versatile and easy to interpret, making it
increasingly used not only in the context of software modeling, but in systems
engineering in general, to represent the functionality of a system and its relations
with the outside world . Moreover, the description of use cases is a technique to
describe functional requirements. Although there is no established standard for
writing the content of use cases, yet there is a set of recommendations and best
practices to ensure that the application of the technique is effective and meets the
objective of facilitating communication between participants in the requirements
process.
Objectives
■Identify actors and use cases in a given system.
■ Represent them in a use case diagram.
■ Understand relations and differences between actors, users and stakeholders.
■ Apply use case diagram to represent system scope.
■ Apply use cases as a description of business and system functional requirements.
■ Apply the scenarios technique to describe use cases.

Building the requirements model

The intent of the analysis model is to provide a description of the required
informational, functional, and behavioral domains for a computer-based
system. The model changes dynamically as you learn more about the system to
be built, and other stakeholders understand more about what they really
require. As the requirements model evolves, certain elements will become
relatively stable, providing a solid foundation for the design tasks that follow.
Elements of the Requirements model
● Scenario-based elements.
The system is described from the user’s point of view using a scenario-based
approach. For example, basic use cases and their corresponding use-case
diagrams evolve into more elaborate template-based use cases. Scenario-based
elements of the requirements model are often the first part of the model that is
developed. As such, they serve as input for the creation of other modeling
elements.
● Class-based elements.
Each usage scenario implies a set of objects that are manipulated as an actor
interacts with the system. These objects are categorized into classes—a
collection of things that have similar attributes andcommonbehaviors

● Behavioral elements.
The behavior of a computer-based system can have a profound effect on the design
that is chosen and the implementation approach that is applied. Therefore, the
requirements model must provide modeling elements that depictbehavior.The state
diagram is one method for representing the behavior of a system by depicting its
states and the events that cause the system to change state. A state is any externally
observable mode of behavior.
● Flow-oriented elements.
Information is transformed as it flows through a computer-based system. The
system accepts input in a variety of forms, applies functions to transform it, and
produces output in a variety of forms. Input may be a control signal transmitted by
a transducer, a series of numbers typed by a human operator, a packet of
information transmitted on a network link, or a voluminous data file retrieved from
secondary storage. The transform(s) may comprise a single logical comparison, a
complex numerical algorithm, or a rule-inference approach of an expert system.
Output may light a single LED or produce a 200-page report.
Negotiating the requirements
In an ideal requirements engineering context, the inception, elicitation, and
elaboration tasks determine customer requirements in sufficient detail to
proceed to subsequent Software engineering activities. Unfortunately, this
rarely happens. In reality, You may have to enter into a negotiation with one or
more stakeholders. In most cases, stakeholders are asked to balance
functionality, performance, and other product or system characteristics against
cost and time-to-market. The intent of this negotiation is to develop a project
plan that meets stakeholder needs while at the same time reflecting the real-
world constraints (e.g., time, people, budget) that have been placed on the
software team.
The best negotiations strive for a “win-win” result. That is, stakeholders
win by getting the system or product that satisfies the majority of their
needs and you (as a member of the software team) win by working to
realistic and achievable budgets and deadlines.
There are a set of negotiation activities at the beginning of each
software process iteration. Rather than a single customer
communication activity, the following activities are defined:

1. Identification of the system or subsystem’s key stakeholders.

2. Determination of the stakeholders’ “win conditions.”
3. Negotiation of the stakeholders’ win conditions to reconcile them into a set
of win-win conditions for all concerned (including the software team).
Successful completion of these initial steps achieves a win-win result, which
becomes the key criterion for proceeding to subsequent software
engineering activities.

Requirements Validation
It’s a process of ensuring the specified requirements meet the customer's needs. It’s
concerned with finding problems with the requirements.These problems can lead to
extensive rework costs when they are discovered in the later stages, 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 code errors. Because a
change to the requirements usually means the design and implementation must also
be changed and re-tested.During the requirements validation process, different
types of checks should be carried out on the requirements. These checks include:

1. Validity checks: The functions proposed by stakeholders should be aligned

with what the system needs to perform. You may find later that there are
additional or different functions are required instead.

2. Consistency checks: Requirements in the document shouldn’t conflict or

different descriptions of the same function

3. Completeness checks: The document should include all the requirements and
constraints.

4. Realism checks: Ensure the requirements can actually be implemented using

the knowledge of existing technology, the budget, schedule, etc.

5. Verifiability: Requirements should be written so that they can be tested. This

means you should be able to write a set of tests that demonstrate that the system
meets the specified requirements.

Requirement Analysis
Requirement Analysis, also known as Requirement Engineering, is the process
of defining user expectations for a new software being built or modified. In
software engineering, it is sometimes referred to loosely by names such as
requirements gathering or requirements capturing.
Objectives of Requirement Analysis
Identify customer's needs.

1. Evaluate system for feasibility.

2. Perform economic and technical analysis.

3. Allocate functions to system elements.

4. Establish schedule and constraints.

5. Create system definitions.
The various steps of requirement analysis are
1. Draw the context diagram: The context diagram is a simple
model that defines the boundaries and interfaces of the
proposed systems with the external world. It identifies the
entities outside the proposed system that interact with the
system.

2. Development of a Prototype (optional): One effective way to

find out what the customer wants is to construct a prototype,
something that looks and preferably acts as part of the system
they say they want.

We can use their feedback to modify the prototype until the customer is
satisfied continuously. Hence, the prototype helps the client to visualize the
proposed system and increase the understanding of the requirements. When
developers and users are not sure about some of the elements, a prototype may
help both the parties to take a final decision.

Some projects are developed for the general market. In such cases, the
prototype should be shown to some representative sample of the population of
potential purchasers. Even though a person who tries out a prototype may not
buy the final system, but their feedback may allow us to make the product
more attractive to others.

The prototype should be built quickly and at a relatively low cost. Hence it will
always have limitations and would not be acceptable in the final system. This
is an optional activity.

3. Model the requirements: This process usually consists of

various graphical representations of the functions, data entities,
external entities, and the relationships between them. The
graphical view may help to find incorrect, inconsistent, missing,
and superfluous requirements. Such models include the Data
Flow diagram, Entity-Relationship diagram, Data Dictionaries,
State-transition diagrams, etc.

Finalise the requirements: After modeling the requirements, we will have a

better understanding of the system behavior. The inconsistencies and
ambiguities have been identified and corrected. The flow of data amongst
various modules has been analyzed. Elicitation and analyze activities have
provided better insight into the system. Now we finalize the analyzed
requirements, and the next step is to document these requirements in a
prescribed format.