Agenda Requirements What are requirements? Classifying the requirements Characteristics of requirements Requirements elicitation Documenting the requirements Requirements analysis and negotiation Requirements validation

1. ITS 66404
Principles of Software
Engineering
Nur Haifa
Chapter 2A-
Software
Requirements

2. Agenda
Requirements
What are requirements?
Classifying the requirements
Characteristics of requirements
Requirements elicitation
Documenting the requirements
Requirements analysis and negotiation
Requirements validation
Chapter 1 – Intro to Software Engineering 2

3. What are requirements?
Requirements are a description or statement of a function, feature or condition
that a user seeks to have implemented in a system.
UML has a modelling technique called "Use cases" to help gather
requirements.
These specify all the different ways people interact with a system.
We examine specific scenarios to test our Use cases.
How will you know when your project is complete?
3

4. Classifying the requirements
There are 2 broad categories of requirements:
Functional Requirements are those that relate directly to the functioning of
the system. These are the aspects of the system the client is most likely
to recognise.
Non-functional requirements cover aspects of the system such as user-
interface, performance, quality issues, interfaces to other systems,
security etc.
4

5. Example functional requirements
User level facility
“The word processor must include a command to check spelling”
System properties
“The system must ensure that personal information is never released without authorisation”
Specific algorithms
“If either hurdle is failed, then the final mark for the subject is the lower of the two percentages”
Specific constraints
“The sensor must be polled 10 times per second”
5

6. Example functional requirements
Legal constraints
The legal system may impose constraints on the behaviour of the software
by either requiring or banning certain behaviours.
“The software must calculate the tax payable and forward it to the Tax
Department”
“The system must ensure that personal information is kept secure
“The system must not allow records to be permanently deleted”
6

7. Example non functional requirements
Constraints on system development
“The system must be developed in Java”
Interface constraints
“The user interface must follow the host operating system’s guidelines”
Performance
“The system must respond to user requests within 2 seconds for 95% of queries”
Interfaces to other systems
“The system should be capable of integrating information from RSS feeds from
websites and displaying them on screen”.
Security
“Only authorised users should be able to access the features listed below…”
7

8. Characteristics of requirements
Requirements are expected to be…
Verifiable
Complete
Unambiguous
Consistent
Modifiable
Traceable
8

9. Characteristics of requirements
Verifiable
A requirements document often becomes part of the contract between a client and a
system developer.
It describes what the developer will deliver and be paid for.
It is important that you can check if the final product fulfills the requirements
Requirements should therefore be verifiable
It should be possible to decide if the software meets the requirements.
Requirements that contain subjective assessments of quality are always
problematic.
Example requirements that can’t be tested.
“The program must be very fast.”
What is a measure for fast?
What aspects should be fast? Startup? File saving? Computation?
9

10. Characteristics of requirements
Verifiable
Example requirements that can’t be tested.
“The system must be able to store all of our customer’s details.”
This could be a moving target - their customer base may be increasing as you develop
the product. You should have a fixed figure.
“The system should be able to initially store 50,000 customers, and be capable of
expanding to 200,000 customers at a small cost”.
Note you would also have to define what “a small cost” meant!
“The GUI should use pleasing colours”
Better wording would be...
“The GUI colours will be chosen by the user from a selection of colours”
“The GUI colours will be chosen from a colour picker by the user”
“The GUI will use colours based on the host operating system’s colour guidelines” 10

11. Characteristics of requirements
Complete
The requirements should be complete, and not leave out any areas.
This can be very hard to achieve, especially in large systems.
Current trends are to break the development up into smaller modules and
implement each of them.
As you can test each implementation, you will have greater faith that
requirements have not been overlooked.
11

12. Characteristics of requirements
Non ambiguous
A requirement is ambiguous if it has more than one possible meaning.
May be ambiguous due to
Poor choice of words
Differing definitions of a word or phrase.
12

13. Characteristics of requirements?
Ambiguous requirements
Poor choice of words
“Apple is working to improve the rest of the Mac OS code to allow for less
busy loops from their side.”
Does this mean that there will be fewer busy loops, or the loops that do
exist will be less busy?
We can see that the problem lies with the adjective “busy” and the
uncertainty as to which noun it applies.
less (busy loops)
(less busy) loops
13

14. Characteristics of requirements?
Ambiguous requirements
Differing definitions of a word
This is especially likely when the common meaning of a word is different from
that used in a specialised area.
“The system will store the time of each transaction”
Should this be the local time, or Universal time?
What precision should the time be recorded in?
In statistics “significant” has a specific meaning (“there is evidence of a
systematic relationship”) that is different from the general meaning
(“having or expressing a meaning”)
14

15. Characteristics of requirements?
Consistent
All parts of the requirements document should be consistent with each other.
They should not contradict each other (the following do).
“If you delete a task all of its subtasks should be deleted automatically”
“You should always be prompted to confirm the deletion of a task and any
of it’s subtasks”
The larger the set of requirements the more likely it is that it will be
inconsistent.
15

16. Characteristics of requirements?
Modifiable
The requirements should be structured so that it is possible to change it at little to no
cost.
Requires it be structured carefully, e.g.
Separating functional from non functional requirements
Supplying a glossary (a table of definitions)
Use of appropriate tools that allow you to browse and automate modifications
Use of hyperlinked (HTML) documentation.
A tool similar to Sun’s Javadoc would be ideal.
16

17. Characteristics of requirements?
Traceable
The requirements should be structured so that it is possible
To uniquely identify each requirement
Each one should have a unique number (e.g. “10.4.2”)
This allows it to be referred to in final testing of the delivered software, and in discussions with a client.
To identify its history
Who requested the feature?
Is it the result of any other feature?
Who authorised it.
Dates these happened
17

18. Requirements engineering
How to get the requirements from the client
Gathering requirements can be very difficult
The client may not have a clear idea of what they want
The problem may be very large and take a long time to fully understand
The requirements may be rapidly changing
The client may not be fully committed to the project and will not spend the
time with you that you need.
They may not understand what you need to complete the task.
They may have unreal expectations of what can be achieved
18

19. Requirements engineering
Requirements engineering is…
requirements elicitation
requirements analysis and negotiation
requirements specification/documentation
requirements validation
19

20. Requirements elicitation
More techniques for finding requirements
Interviews
Focus groups
Scenario modeling
Questionnaires, Observations, Sampling
UML Use Case diagrams, Rational Unified Process
20

21. Requirements elicitation
Interviews
The aim is to gather information that may not be documented.
Always arrange in advance and give people being interviewed an agenda
(a list of topics to be discussed).
Clarify note taking arrangements
Who will write down what happens during the meeting?
Ensure unanswered questions are noted, allowing you to follow up on them
later.
21

22. Requirements elicitation
Interviews
Follow up the interview with a report to the person being interviewed
covering the points made.
This helps ensure that you have the facts correct. If any errors are
discovered you should arrange another interview to clarify the
problems.
Interviews should be restricted to smaller groups. Larger groups tend to
defer to the most senior person in the room, sometimes resulting in one
person’s point of view only.
22

23. Requirements elicitation
Interviews
Respect confidentiality.
If people trust you to keep secrets, they may be willing to divulge a lot
more information
Historical reasons for certain decisions
Personality traits for people in the organisation (e.g. you may find that someone often
lies about what they do, or that they blame others for their mistakes).
You need to be careful as some people will take advantage of this to
advance their own position in detriment to others.
23

24. Requirements elicitation
Interviews
Open-ended/Probing questions
Interviews often work best when a specific set of questions are asked.
Probing questions generally are used to validate (or invalidate) a model
being built by the requirements engineer.
Open ended questions are used to allow the user to elaborate on things
they feel are important.
24

25. Requirements elicitation
Interviews
Have a mix of open-ended and probing questions
Three sets of questions are appropriate. Questions which:
focus on the customer, his/her overall goals and the benefits of the system
to them
give the analyst a better understanding of the problem, and/or give the
customer the opportunity to voice their ideas about possible solutions
check the effectiveness of the meeting.
25

26. Requirements elicitation
A loaded question is one where you have meanings embedded into the
question
For example...
“Would you like to use the C language, or would you put up with Java?” is loaded,
because it implies that Java is something people wouldn't want to use.
“Can you begin to appreciate the wonderful opportunity you are being offered?”
The question is not impartial. It is disingenuous to ask such questions, as it strikes at
the heart of a meaningful interview - one where you are interested in another
person's opinion.
26

27. Requirements elicitation
Focus groups
A focus group is a group of people who meet to focus on some issue
relevant to the problem being solved. They typically include
Requirements engineer/Systems analyst
Problem domain expert (e.g. an accountant if you are developing
accountancy software, or a lawyer for a legal system).
People who are authorised to make decisions.
27

28. Requirements elicitation
Scenario modeling
Scenario modeling attempts to identify how a system works by getting
current users to talk through/demonstrate how they handle situations.
Very useful as it helps highlight processes that are often not discussed
because they are “obvious”
These are so useful that there is a notation for recording them in UML
Use Case, Sequence, Collaboration and Activity diagrams.
28

29. Requirements elicitation
Understanding requirements
The traditional model of developing systems had all of the requirements
completed before undertaking any analysis of them.
This does not work, as it is impossible to know if you are asking sensible
questions, or whether there are any contradictions or ambiguities in the
requirements without analysing them.
Eliciting requirements therefore requires that an analysis be done at the
same time or iteratively.
29

30. Requirements elicitation
Understanding requirements
In some situations the analysis (understanding of the problem) may require you to
perform
Prototyping
Creating a small simple implementation of a part of the system
This can be shown to the client for confirmation of your ideas.
Proof of concept work
Develop a small simple implementation to test if the idea is feasible.
In all cases this extra work allows you to construct a more accurate requirements
document.
30

31. Problem
Chapter 1 Introduction 31
Imagine MyTiMES is not available on mobile, but only on desktop. It is so difficult to
submit assignments, post latest updates and to review, when not on desktop.
A lecturer (user) , post this pain points to ICT Helpdesk, and the IT department
decides to develop a mobile app.
Please provide potential user requirements and systems requirements
Provide possible requirements elicitation.

32. THE END
Question?