SOFTWARE REQUIREMENT ENGINEERING

LAB 01
Introduction To Requirement Engineering

OBJECTIVES:

✔ Learn what the requirement are?

✔ Characteristics of good user requirements.

Requirements:

Something required, something wanted or needed

✔ Need- something you have to have
✔ Want -something you would like to have

Software Requirement:

A complete description of what the software system will do without describing how it will do
it is represented by the software requirements

Requirement Engineering:

Requirements engineering is composed of four key activities – requirements elicitation,

requirements analysis and negotiation, requirements specification or documentation and
requirements validation.

Software Requirement Engineering:

✔ What: The various levels and types of requirements that need to be defined
✔ Why: The benefits of having the right software requirements
✔ Who: The stakeholders of the software requirements and getting them involved in the
process
✔ When: Requirements activities throughout the software development life cycle
✔ How: Techniques for eliciting, analyzing, specifying, and validating software
Requirements

TASK 1:

Consider in the following grocery list example. Identify requirements error in this list.

1. Milk
2. A loaf of bread
3. Orange juice
4. A box of cereal
5. Butter

Characteristics of Good User Requirements

⮚ COMPLETE:

They include all of the necessary elements; functionality, external interfaces, internal
interfaces, design constraint, and quality attributes,Complete requirement leaves no one
guessing (For how long?, 50 % of what?), and includes measurement units (inches or
centimeters?).

⮚ CORRECT:

They accurately reflect the real needs of users and business stakeholders.

⮚ CLEAR :

They are understood by all stakeholders without the need for extensive explanation.

⮚ CONSISTENT:

They do not conflict with other requirements (conflicting requirements should be addressed
ASAP in the requirements elicitation process).

⮚ RELEVANT:

This may seem obvious, but it is sometimes easy to get off-track and you can end up with
requirements that are not necessary for that particular project. To avoid this, make sure the
requirements meet a business need, goal, or objective.

⮚ VERIFIABLE :

There must be way to verify if the requirement is satisfied. Verifiable requirement is stated in
such a way that it can be tested by: - inspection, - analysis, or - demonstration. Makes it
possible to evaluate whether the system met the requirement

⮚ FEASIBLE (Realistic, Possible):

The requirement should be doable within existing constraints such as time, money, and
available resources:

⮚ AMBIGUOUS:

Requirements that:
✔ have any kind of ambiguity.
✔ have more than one type of interpretation.
Any task in requirements that can have more than one correct output that is contingent on a
different understanding of the task is ambiguous.
TASK 2:

Do you find any requirement errors in given statements. If yes:

Identify the type of error and write corrected version of these statements.

🡺 REQ1: On loss of power, the battery backup must support normal operations.

🡺 REQ2: The system shall not accept passwords longer than 15 characters.

🡺 REQ3: The system shall have a natural language interface that will understand
commands given in English language.

🡺 REQ4: The replacement control system shall be installed with no disturbance to

production.

🡺 REQ5: The system shall resist concurrent usage by many users

TASK 3:

A requirement that says “Users should be able to move more quickly between screens” is not
verifiable. Why?

TASK 4:

What will you end up with when you are asked “to divide 8 in a half”.