Requirements Engineering

Review and Advise

Requirements Engineering
A method of obtaining a precise formal

specification from the informal and often

vague requirements with customers.

The science and discipline concerned with

analyzing and documenting requirements.
It comprises needs analysis, requirements
analysis, and requirements specifications.

RED SUN Inc.

Review
Major issues of requirements engineering processes are a
result of failing to make a clear separation between different
levels of requirements.
Different levels of requirements are useful because they
communicate information about the system to different
types of readers.
Business requirements should be written for a senior
manager and system owner.
User requirements should be written for stakeholders and
users who may not have detailed technical knowledge of
the system.
System requirements should be written for architects,
system engineers, and project managers.
BIM requirements should be written for BIM
developers who will develop the system.
RED SUN Inc.

Review
Business Requirements = Why?
User Requirements = What?
System Requirements = What is it?
BIM Requirements = How?
Functional Requirement = Behavioral requirements
(System shall do or shall let user do).
Non-Functional requirements = Quality attributes
(Products characteristics).

Requirement Engineering is an iterative process

of gathering, analyzing, documenting, validating.
If you do not get the requirements right, it does
not matter how well you execute the rest of the
project.

RED SUN Inc.

Where Do Requirements Come From?

Business
Requirements

User Requirements

System Requirements

BIM Requirements

RED SUN Inc.

Why the project is

being undertaken

What users will

be able to do

What systems need

to be built

What BIM needs to

be developed

Business Requirements
Statements of the business rationale for
authorizing the project. They include a vision for
the BIM product to be built that is driven by
business goals, objectives, and strategy.
Business requirements describe the high level
purposes and needs that the BIM product will
satisfy, the view of its accomplishment for the
users, its features, functions, and capabilities
from the Business point of view.
Business requirements are documented in the
Project Charter, Vision or Scope of the project.
Sometimes it can be found in the Statement of
Work, Memo of Understanding (MoU) or Request
for Proposal (RFP).
RED SUN Inc.

User Requirements
The definition of the entire system (hardware and
BIM) from the Users point of view. They
describe the task that users need to do with the
system to accomplish a business function.
User requirements are the bridge between the
business goals (Business language) and the
system requirements (Technical language). BIM
Engineers must understand how users will use the
system and derive their requirements from the
user requirements document.
User requirements can be found in the User
Requirements Document (URD), Concept of
Operations (Con OP), User Scenarios / Use-cases
or Product features document.
RED SUN Inc.

System Requirements
Detailed descriptions of all functional as well as
non-functional requirements that the systems
(Hardware and BIM) must do to meet business
and user needs.
System requirements define the top level
requirements for allocation to hardware, BIM or
subsystems from the System Engineers point of
view. (Manager, Architect, Designer)
System requirements serve as a communications
channel to users, procurement organizations, as
well as to system architects who are concerned
with the development of system elements or
components.
RED SUN Inc.

BIM Requirements
BIM requirements are detailed descriptions of all
functional and non-functional requirements that
the BIM must do to meet system requirements
and user needs from the Developers point of
view.
BIM requirements establish an agreement
between technical people and business people on
what the product or application must do while
staying within the constraints of system
architecture and hardware limits.
BIM Requirements are documented in BIM
Requirements Documents (SRS), Detailed
Requirements Specifications or Functional
Specifications.
RED SUN Inc.

Basic Types of Documents

Business Requirements Document (BRD)
Users Requirements Document (URD)
System Requirements Document (SRD)
Functional Requirements Document (FRD)
Architecture Design Document (ADD)
Hardware Requirements Document (HRD)
BIM Requirements Specification (SRS)
Interfaces Definition Document (IDD)

RED SUN Inc.

10

Documentation
WHY

WHAT

HOW WELL

Vision

System Goals

Goals

User
Requirements

Objectives

System
System Goals Requirements
Functional
Business
Requirements Requirements

HOW

User
Requirements

System
Architecture

System
Performance

System
Constraints

System
Constraints

BIM
Requirements

Non-Functional
Requirements
(Quality attributes)

RED SUN Inc.

11

Relationships Of Requirements
Requirements

Business
Requirements

Document

Users view

Vision & Scope

Users
Requirements

System
Requirements

Use-case
BIM
Requirements

Hardware
Requirements

Developers view

BIM Requirements
Specification
RED SUN Inc.

12

How Long Do Requirements Take?

For a system approximately one million
lines of Model or 10,000 Points in
Function size:
Project Type

Percent Of Total Effort

Duration
(In Month)

3.7%

4.45

9%

13.2

Information System
Systems BIM
Commercial Products
Military BIM
Outsourced Project

7%

22.7

10%

17.5

9%

21.9

Based on Industry benchmark by Casper Jones - 2000

RED SUN Inc.

13

Factors That Influence Time

Highly skilled and experienced BIM
engineers.
khch hng tham gia cng nhi u
Extensive stakeholder involvement. thcngi gian
rt ng n th i gian l y ycau.

Clear and stable vision and scope.

li nh ng ti li u, s n ph m
Reuse artifacts from previous projects. dng
c a d n tr c

Stakeholder responsiveness. m

p ng c a stakeholder

Effective process and capability of organization.

c qui trnh hiu

qu v n ng l c

Effective reviews to remove ambiguity and find

m h
omissions.
Strong collaboration teamwork.
Testable requirements.

RED SUN Inc.

14

Specific Skills
BIM Engineers who are involved in
requirements elicitation must be able to:
Ask direct questions about who the stakeholders are.
Ask the stakeholders expectations of you.
State clearly what you want from the stakeholders.
Ask directly for the stakeholders concerns about costs,
quality and time, and other issues.
Reach agreement with stakeholders.
Ask for feedback about control and commitment.
Ask how you and stakeholders will know if you are
successful.
Ask for open communication channels.
Get feedback early.
RED SUN Inc.

15

Requirements Development Process

Re-Evaluate

Elicitation

Analysis

Specification

Clarify

Validation

Re-Write

Correct and close gaps

Iterative process - Multiple-steps, Not sequential

RED SUN Inc.

16

Definitions
Requirements Elicitation

Techniques used by BIM Engineers to determine the needs

of stakeholders, so that systems can be built with a high
probability of satisfying those needs.

Requirements Analysis

The techniques of deciding which features are appropriate

for the product based on stakeholders needs.

Requirement Specification
The techniques of documenting the external behavior of a
system that will be built based on the features selected
during the analysis process.

Requirement Verification & Validation

The techniques of ensuring that a requirements specification
meets the stakeholders needs.
* IEEE Standard 610.12 IEEE Glossary of BIM Engineering Terminology

RED SUN Inc.

17

Review: Elicitation
Requirements elicitation is the technique of
understanding stakeholders needs and collecting
them for future analysis.
Note: The needs can be expressed abstractly
such as a problem statement: I want to
reduce my financial error rate by at least 35%
or specifically as a solution statement: I want
to have a large icon on the screen display.
All these needs are called Features.
Do NOT confuse feature with functionality.
A feature may have several functions.

RED SUN Inc.

18

Requirements Are:
Inputs into system.
Outputs from system.
Relationships between inputs and outputs.
Scenarios, a combination of inputs, outputs to
perform a user-needed function.
User classes: Variety of types of users.
Environment: Technology, platform, hardware,
system required for system to operate.
Response time to a stimulus.
Interface describes the interface between users
and system or system to system.
RED SUN Inc.

19

Before Starting Elicitation

What problems are they encountering?
What outcomes are they expecting?
What kind of proposal is this?
Who owns the system after it is
completed?
Is this a technical solution looking for a
problem to solve?
Document your assumptions, then verify
them with stakeholders.

RED SUN Inc.

20

Questions To Ask
What is the problem to be solved?
What are the constraints?
Cost, resources, efforts
Deadlines, schedule
Performance, scalability
Platform, technology
What are the needs?
Successive refinement (Iterative).
Technical feasibility.
Financial justification.

RED SUN Inc.

21

Ask for Outcomes, Not Solutions

Ask not for
solutions:
Ask for
outcomes:

What do you
want?

What do you want our products

to do for you?

RED SUN Inc.

22

Business Requirements
BIM Engineers engaging in requirements
development need to have an understanding of
the business opportunities being proposed.
BIM Engineers need to understand business
goals and objectives, criteria, product vision,
project scope and boundaries.
Business requirements answer the question: Why
are we doing this project?
Typical stakeholders who participate in this
activity are senior managers, system owners
(customers who will buy or pay for this system)
and product managers.
RED SUN Inc.

23

Eliciting Business Requirements

What business problem are you trying to solve?
What is the motivation for solving this problem?
What would a highly successful solution do for you?
How can we judge the success of the solution?
What is a successful solution worth?
Who are the people or groups that could influence this
project?
Who are the people and groups that would be influenced by
this project?
Are there any related projects or systems that could
influence this project or that this project could affect?
Which business activities should be included in the solution?
Can you think of any unexpected or adverse consequences
that the new system could cause?

RED SUN Inc.

24

User Requirements
The business requirements will help identify
potential users for the product or system.
BIM Engineers who engage in requirements
development need to understand what the users
are able to do with the product and how the
product will enable them to achieve specific goals.
The users goals must align with the business
goals in the business requirements.
There are two types of users goals: Functio nal
and Non-functional (Quality attributes) that
BIM Engineers must capture to gu de the
i
development efforts.
Users requirements also help testers to
determine whether the final product satisfies its
requirements.

RED SUN Inc.

25

Eliciting User Requirements

What are some reasons why you would use the
new product?
What goals do you have in mind that this product
could help you accomplish?
What problems do you expect this product to
solve for you?
What external events are associated with this
product?
What words would you use to describe this
product?
Are specific portions of the product more critical
than others for performance, reliability, security,
availability or others?
RED SUN Inc.

26

Eliciting User Requirements

How is the product you envision similar to the
way you do business now? How should it be
different?
What aspect of the current product or business
process do you want to retain or replace?
Which aspects of the product are most critical to
creating business value?
What aspects of the product are most exciting to
you?
What aspect of the product will be most valuable
to you or least valuable to you?
RED SUN Inc.

27

Eliciting User Requirements

What is important to you about the product?
Are there any constraints to which this product
must conform?
How do you judge whether the product is a
success?
Can you describe the environment in which the
product will be used?

RED SUN Inc.

28

Why Are Requirements Difficult?

In your organization, what percent of people have
excellent writing skills?
Of those, how many understand the intricacies of
writing BIM requirements?
Of those, how many are in a position where
writing requirements is part of their job?
Of those, how many are trained in requirement
engineering?

RED SUN Inc.

29

To Reduce Errors
BIM Engineers can improve requirement
development processes by:
Use of effective requirements elicitation
techniques.
Write requirements with an targeted audience
in mind.
Use simple techniques to reduce ambiguity.
Review requirements from different
perspectives.
Remember that requirements development is an
iterative and communication intensive.

RED SUN Inc.

30

Write For Targeted Audience

Write requirements with an audience in mind by
identifying who will be reading the requirements:
Project Manager
Developers
SQA Staff
Technical Writers
Product Marketing
Training Personnel
Support Personnel
Others?
Make sure to ask them to identify the kinds of
information they need to do their job.
RED SUN Inc.

31

Use Simple Techniques

Use pictures to illustrate work flow and
functionality.
Create a glossary and use terms consistently.
Every requirement must be clearly identified and
numbered.
Use short sentences average < 20 words per
sentence.
Use the phrase: The BIM shall and avoid
ambiguous words such as: could, would,
should, may, might, or user-friendly, etc
Use good document outlines, templates.
Use checklists whenever you can.
Build your own checklists and continue to refine
them for future use.

RED SUN Inc.

32

Improving Reviews
Do not expect reviewers will know what to do, BIM
Engineers may need to educate reviewers by
providing training on how to perform a review or
inspection.
Do not wait until a requirements document is
complete before conducting a review. BIM
Engineers must schedule reviews incrementally,
anytime a phase or a part of the requirement
document or model is ready.
Give reviewer a few pages or a model to review,
do not overwhelm reviewers.
BIM Engineers must plan for several reviews over
time as requirements progress.
RED SUN Inc.

33

Requirement Changes - 1
Fact:
The more requirements you give a stakeholder,
the more they will want.
The more requirements you agree to satisfy,
the more they will want.
The more requirements you talk about, the
more they will want.

Solution:
Do not suppress discussion & agreement.
Facilitate changes.
Shorten development cycle (incremental
release, agile development etc.).
RED SUN Inc.

34

New Requirements - 1
Fact:
New requirements appear as development
efforts progress.

Options:
Accept the new requirement and increase risk
of being late or over budget.
Accept the new requirement and extend the
schedule or budget.
Accept the new requirement and delete other
requirements.
Exclude new requirements because additional
risk and delaying schedule is not acceptable.
RED SUN Inc.

35

New Requirements - 2
Solution:
First, try to accept the new requirement
without changing schedule or budget.

Can we tolerate an increase in budget risk from 25%

to 40%?

Can we tolerate an increase in schedule risk from

20% to 45%?

Second, try to accept new requirements with

some modification of schedule and budget but
need renegotiation.
Third, try to accept new requirements by
deleting others (this will make some
stakeholders very upset).
RED SUN Inc.

36

A Good Requirements Have

A clear vision.
A well-defined scope.
A well-defined stakeholders elicitation strategy.
A combination of multiple requirements elicitation
techniques.
Requirements developed in an iterative manner.
Combined text and visual analysis model.
Requirements reviews conducted.
Prioritized requirements.

RED SUN Inc.

37

Reasons for Not Doing Requirements:

1. We have already started coding, and don't want to spoil it.
2. It's easier to change the system later than to do the
requirements up front.
3. The problem is too complex to write requirements.
4. My boss frowns when I write requirements.
5. It's too hard to do requirements.
6. We don't have time to do requirements.
7. Who cares what the users want?
8. We already know what the users want.
9. The users don't know what they want.
10. We don't need requirements, we're using objects /java and
web/.

This work is copyright Atlantic Systems Guild Limited, but may be adapted for your internal use provided copyright is
acknowledged.

RED SUN Inc.

38

Questions & Answers

RED SUN Inc.

39