Requirements Engineering

1
Requirements Engineering

• T-76.4115 Software Development Project I
• 4.10.2005
• Sari Kujala
• Sari.Kujala_at_tkk.fi

2
Outline

• Requirements engineering
• Requirements gathering interviewing
• Requirements analysis

3
What is Requirements Engineering (RE)?

• The earliest phase of the software development
  life cycle
• The goal is assure that a correct and good
  product is defined and developed from the
  stakeholders point of view
• Possible stakeholders are customers, users,
  engineers responsible for system development and
  maintenance

4
Why RE is important?

• Detecting and correcting errors can be up to 200
  times more expensive in the maintenance phase
  compared to the RE phase (Davis, 1993).
• More time and effort invested in the early stages
  of a software project yields faster cycle times
  and higher productivity (Blackburn et al., 2000).

5
Requirements in the Software Process
Requirements definition
Analysis design implementation testing
Acceptance testing
Requirements management
6
RE process (Kotonya Sommerville, 1998)
7
User Requirements

• User requirements describe any function,
  constraint, or other property that must be
  provided to satisfy the user needs.
• User requirements are written from user point of
  view (vs. technical requirements).

8
User Requirements
user group A
user group B

• User requirements tell WHAT the system shall do
  from users point of view.
• Users are not interested in technical details.
• The system is seen as a black box.

9
Classification of requirements

• Functional requirements define system functions
• HERE the name of the high-level use case
• Non-functional requirements describe system
  qualities
• User requirements describe the tasks that the
  user or another system will accomplish using the
  system
• HERE use cases

10
Non-Functional Requirements

• Look and Feel Requirements
• Usability Requirements
• Performance Requirements
• Operational Requirements
• Maintainability and Portability Requirements
• Security Requirements
• Cultural and Political Requirements
• Legal Requirements

11
Use cases (1/2)
ID Nimi Prioriteetti
UC1 Sisäänkirjautuminen Pakollinen
UC2 Uloskirjautuminen Pakollinen
UC3 Testausprojektin luominen Pakollinen
12
ID Use Case 1
Nimi Sisäänkirjautuminen
Tiivistelmä Rekisteröityneen käyttäjän sisäänkirjautuminen
Toimijat Kaikki käyttäjät pois lukien asiakas
Alkuehdot  -
Perussekvenssi Järjestelmä kysyy identifiointia (käyttäjätunnus, salasana Käyttäjä syöttää käyttäjätunnuksen ja salasanan Järjestelmä tarkistaa käyttäjätunnuksen ja salasanan Järjestelmä päästää käyttäjän sisään kirjautuvan käyttäjän oikeuksilla
Poikkeukset 4a. Jos käyttäjätunnus ja salasana pari ei täsmää, järjestelmä tulostaa virheilmoituksen
Jälkiehdot Käyttäjä on sisäänkirjautunut järjestelmään kyseisen käyttäjän oikeuksilla
Viittaukset testitapauksiin ST-1, ST-2, ST-3
13
Requirement gathering (or elicitation)

• The goal is to understand
• the domain area
• the problem to be solved
• the needs of the stakeholders

14
Why customers and users are involved?

• The goal of a new product is to solve a problem
  in the real world and users are experts in
• problems to be solved
• tasks to be supported
• context and domain area
• Involving users and customers as the source of
  information is related to project success and
  lower costs (Kujala et al., 2005).

15
Requirements gathering in practice

• Gather and check the existing material
• Identify users and other stakeholders
• Describe the main user groups
• Gather customer and user needs by interviewing
  and observing
• Document customer and user needs e.g. as a list
• Record the source where the needs were gathered

16
How to gather user needs? (1/2)

• Select different users from different user
  groups typical and advanced lead users
• Watch, listen to, and talk with users in their
  own environment
• Try to understand their goals and values, present
  ways of doing the tasks, underlying reasons for
  the behavior or wants

17
How to gather user needs? (2/2)

• Treat users as experts
• Keep the conversation concrete
• Ask users to show how they do things
• Gather critical incidents (how it happened last
  time, yesterday)
• Look at used notes, paper and pencil tasks,
  forms, modifications users have made

18
Interviewing questioning

• Listen to interviewee, dont be too quick in
  offering an interpretation
• Ask one question at a time
• Avoid leading and complex questions
• Let user freely express himself, let a moment to
  think about

19
Interviewing information gathering

• Ask the user first to tell about his/her work or
  situation generally
• Try to understand the activities of the user
• Use information that users provide as the basis
  for further questioning

20
The language of customers and users

• Remember that all kind of information is not easy
  to tell (e.g. skills)
• Collect users terminology and use them (be
  careful not to use technical terms)
• Make minimal assumptions about users and the
  information that they are giving
• Also familiar terms can have different meaning
  for users