Understanding Requirements

1
Understanding Requirements
2
Requirements Engineering

• Requirements Engineering refers to the broad
  spectrum of tasks and techniques that lead to and
  understanding of requirements.

3
Why is Requirements Engineering so important?

• Case Study
• A credit union needs a software that allows them
  to enter member information. The software will
  update and back up the database. It should keep
  track of All personal information, account info.,
  and loan info.

4
Possible problems with this situation

• The specific needs are not clear
• We do not know if this is feasible
• Will this software be cost effective?
• The customer is not a specialist. They most
  likely do not know what they need.

5

• I know you think you understand what I said, but
  what you dont understand is what I said is not
  what I meant.

6
7 Steps of Requirements Engineering

• Inception
• Elicitation
• Elaboration
• Negotiation
• Specification
• Validation
• Management

7
Inception
Establish a basic understanding of the problem,
the people who want a solution, the nature of the
solution that is desired, and the effectiveness
of preliminary communication and collaboration
between the other stakeholders and the software
team.
8
Elicitation

• Problems of Scope. The boundary of the system is
  ill-defined
• Problems of Understanding. The customers are not
  completely sure of what is needed, have a poor
  understanding of the limitations of their
  environment, and have a hard time communicating
  their needs to the engineer.
• Problems of Volatility. The requirements change
  over time
• One must approach requirements gathering in an
  organized manner in order to avoid these problems.

9
Elaboration

• The process of expanding and refining the
  information obtained from the customer during
  INCEPTION and ELICITATION.
• Develop a refined requirements model (chapters 6
  7).
• Driven by creation and refinement of user
  scenarios that describe how the end user will
  interact with the system.

Hardware failure
10
Negotiation

• Customers often times ask for more than what can
  be achieved given limited resources, etc
• You must reconcile all conflicts through a
  process of negotiation

11
Specification
Can be a written document, a set of graphical
models, a formal mathematical model, a collection
of usage scenarios, a prototype, or any
combination of these. A popular method is using
a standard template for specification so
requirements are consistent and understandable.
12
Validation
Requirements Validation examines the
specification to ensure that all software
requirements have been stated unambiguously that
inconsistencies, omissions, and errors have been
detected and corrected and that the work
products conform to the standards established for
the process, the project, and the
product. Performed by software engineers,
customers, users, and other stakeholders.
13
Requirements Management
A set of activities that help the project team
identify, control, and track requirements and
changes to requirements at any time as the
project proceeds. Requirements for
computer-based systems are constantly changing.
14
Establishing the Groundwork
15
Establishing the Groundwork

• Rarely is it as simple as conducting
  conversations with colleagues who are well known
  members of the team.
• Customers have limited technical knowledge
• Customers may be located in different
  geographical areas
• Customers may have vague ideas and opinions of
  what is required.
• Customers may have limited time to interact with
  the requirements engineer

16
Identifying Stakeholders

• Stakeholder
• Anyone who benefits in a direct or indirect way
  from the system which is being developed.
• These can be
• Business operations managers
• Product managers
• Marketing people
• Customers
• End users

17
At inception, one should consider who will
contribute input as requirements are
elicited. This list will grow as stakeholders
are contacted. Whom else do you think I should
talk to?
18
Working Toward Collaboration

• The requirements engineer must identify areas of
  commonality and areas of conflict or
  inconsistency.
• Effective collaboration methods include
• Stakeholder voting
• Electing a project champion, an experienced
  business manager or senior technologist, to make
  the final decision about which requirements make
  the cut.

19
Asking the First Questions

• Questions asked at the inception of the project
  should focus on the customer and other
  stakeholders.
• Who is behind the request for this work?
• Who will use the solution
• What will be the economic benefit of a successful
  solution?
• Is there another source for the solution that you
  need?

20
Asking the First Questions

• After initial questioning, ask questions to gain
  a better understanding of the problem at hand and
  any opinions about the solution.
• How would you characterize good output that
  would be generated by a successful solution?
• What problems will this solution address?
• Can you show me the business environment in which
  the solution will be used?
• Will special performance issues or constraints
  affect the way the solution is approached?

21
Asking the First Questions

• The final set of questioning focuses on the
  effectiveness of the communication activity
  itself.
• Are you the right person to be answering these
  questions?
• Are my questions relevant to the problem that you
  have?
• Can anyone else provide additional information?
• Should I be asking you anything else?

22
Asking the First Questions
These questions will help break the ice and
initiate the necessary communication for a
successful project
23
Eliciting Requirements
24
Eliciting Requirements

• Combines elements of problem solving,
  elaboration, negotiation, and specification to
  gather requirements

25
Collaborative Requirements Gathering

• Guidelines
• Meetings are conducted and attended by both
  engineers and other stakeholders.
• Rules for preparation and participation
  established.
• An agenda is suggested that covers important
  points AND encourages free flow of ideas.
• A facilitator controls the meeting.
• A definition mechanism is used.
• The goal is to identify the problem, propose
  solutions, negotiate approaches, and identify
  solution requirements.

26
Quality Function Deployment

• A Quality management technique that translates
  the needs of the customer into technical
  requirements for software.
• It identifies three types of requirements
• Normal Requirements
• Expected Requirements
• Exciting Requirements

27
Quality Function Deployment

• Uses customer interviews, historic data, etc as
  raw data for the requirements gathering activity.
• Data is then transferred into a customer voice
  table, which is simply a table of requirements.

28
Usage Scenarios

• Developers and users create a set of scenarios
  that identify a thread of usage for the system to
  be constructed.
• This helps developers better understand how
  different functions and features will be used.

29
Developing Use Cases
30

• A use case is a story about how an end user
  interacts with the system under a specific set of
  circumstances.

31
Building the Requirements Model

• The intent of the requirements model is to
  provide a description of the required
  informational, functional, and behavioral domains
  for a computer-based system

32
Negotiating Requirements

• Successful completion of negotiation activities
  results in a win-win set of requirements, which
  is key when proceeding to subsequent software
  engineering activities.

33
Validating Requirements

• As each element of the requirements model is
  created, it is examined for inconsistencies.
  Requirements are then prioritized.