Requirements Engineering

Prioritize and Validate

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.

Requirements Prioritization & Validation

BIM Engineers always work under certain
constrained conditions (time, cost, quality), and
can not implement all requirements as stated.
Requirements must be prioritized and validated to
ensure that they provide an accurate account of
stakeholder requirements.
Requirements validation is difficult because it has
to solve the question of truth and what is
knowable, as well as reaching agreement among
different stakeholders with conflicting goals.
These activities require intensive communication
and negotiation between stakeholders and project
teams.
RED SUN Inc.

Constraints
When stakeholders expectations are high but time
and resources are short, BIM Engineers must
make sure the project delivers the final product
on time, within cost and still satisfy stakeholders:
With these Requirements
With limited Budgets
With strict Schedules
Within these Constraints

How can a development team build a system that

meets the business objectives and satisfy
stakeholders?
Answer: Prioritize requirements by high priorities and
eliminate or defer lower priorities to a later release.
RED SUN Inc.

Prioritization Technique: Step 1

Review all requirements with stakeholders and have
them prioritize by Vote (Yes, No) to identify:
Must have (Essential - High)
Should have (Desirable- Medium)
Nice to have (Optional - Low)
Must Have: Without these functions, system is NOT a
system, business problem will NOT be solved.
Should Have: Very important features that
distinguish a system from others, significant to users
and business.
Nice to Have: Other features that could enhance the
system but not significant enough.
RED SUN Inc.

Issues
Stakeholders have different perspectives
and needs.
Stakeholders may come up with 80%-90%
high priority needs because most things
are important to them.
I need all those functions!
I am the customer, and I want that!

It is difficult to convince all stakeholders.

BIM Engineers must eliminate some that
are not essential by continuing to refine
the priority further.
RED SUN Inc.

Refine Prioritization: Step 2

List all prioritized requirements (Must, Should,
Nice to have).
Implement satisfaction index:
From a scale from 1-5 how satisfied would you
be if we implement this requirement (or NOT) .
Consolidate scores and validate requirements
based on this prioritized scheme.
Resolving conflict among requirements.
Revise prioritized requirements list and reduce
some Must have to Should have or Nice to
have.

RED SUN Inc.

Priority Refinement
Stakeholder A

Stakeholder B

Stakeholder C

Stakeholder D

Priority
Score

Requirement #1

4.75

Requirement #2

5.75

Requirement #3

6.75

Requirement #4

3.25

Requirement#

Base on this example, Requirement # 3 has the highest priority with the score of 6.75

RED SUN Inc.

Questions To Ask
Is there some other way to meet the need that
this requirement addresses?
What would the consequence be of eliminating or
deferring this requirement?
What would the impact be on the business goals if
this requirement were not implemented now?
Why would a user be unhappy if this requirement
were deferred to a later release?
Do you really need this feature now or can you
wait until the next release?

RED SUN Inc.

Further Refinement: Step 3

List all refined prioritized requirements.
Estimate the relative value and cost of each
requirement.
Priority: requirements that have the largest
fraction of the total product value at the smallest
fraction of the cost.
Have stakeholders estimate the relative benefit
that each requirement would provide value, on a
scale from 1 to 9 where 9 is the highest.
Have project teams estimate the relative cost to
implement each requirement using the same
scale.
Have project team estimate the relative risk to
implement each requirement (same scale).

RED SUN Inc.

10

Further Refinement
Using a spreadsheet to list requirements,
values, costs and risks, and calculate from
the highest to lowest priority factor.
Priority value = Value/(Cost + Risk/2).
Requirement #

Value

Cost

Risk

Priority

Requirement # 5

1.07

Requirement # 18

0.3

Requirement # 25

0.6

Note: In this example, Requirement # 5 has the highest priority value.

RED SUN Inc.

11

Last Questions
Prioritization scheme is relative, not all
stakeholders will be happy, engineers still have to
validate priorities with stakeholders:
Would your product suffer in comparison with
others that have that capability?
Would there be any legal or contractual
consequences?
Would you be in violation of any legal or
regulatory issues if we do not have these
features?
Would users be unable to perform some
necessary or expected functions?
Would it be much harder to add that feature
later?
RED SUN Inc.

12

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.

13

Verification & Validation

Requirements Verification:
The process of checking that a deliverable
produced at a given stage of requirements
development satisfies the conditions or
specifications of the previous stage.
Verification ensures that you build the BIM
correctly.
Requirements Validation
The stage of BIM development in which the
product is checked to ensure that it satisfies
its intended use and conforms to its
requirements.
Validation ensures that you build the correct
BIM.
RED SUN Inc.

14

Requirement Validation
The techniques of ensuring that a
requirement specification meets the
stakeholders needs.
Requirements validation ensures that the
requirements are necessary and
sufficiently specified to meet stakeholders
needs before development begins.
Requirements validation activities detect
and correct any unnecessary and incorrect
requirements.
RED SUN Inc.

15

Requirements Validation Process

Requirements
Documentation

Select Requirements
Validation Techniques

Validate the
Requirements

RED SUN Inc.

Revise the
Requirements
Documentation

BIM
Development

Ensure Adequate
User Involvement

16

Requirements Validation
1. Validation with Stakeholders
To formally verify requirements to make sure
they meet their needs.

2. Validation with Management:

To provide confidence that the requirements
are reasonable and in alignment with business
goals and objectives.
Sometimes attended by both management
and stakeholders.

3. Validation with Project Team:

To clarify some quality attributes or find
defects.
RED SUN Inc.

17

Validation with Stakeholders

A list of Requirements sorted by attributes:
Priority
Cost
Risk
Volatility
Dependencies (Relationships between
requirements)
Stakeholders could change priority order.
Resolve conflicts among requirements between
different stakeholders, if possible.
The approved fully-attributed requirements will
serve as a baseline for future changes.
RED SUN Inc.

18

Validation by Management
Ensure requirements meet business
needs.
Ensure requirements are in alignment
with business goals and objectives.
Verify business case of requirements.
Clarify that all requirements are
documented correctly.

RED SUN Inc.

19

Validation By QA
Quality Assurance reviews requirements to:
Identify any standard non-compliance.
Ensure it follows organizational templates
and guidelines.
Ensure it is documented, well written,
clear, and complete.
Ensure it can be used by intended
readership.
Check before baselined by Configuration
management.

RED SUN Inc.

20

Approved Requirements
A good requirements specification is:
Documented
Clear and concise
Understood
Testable
Usable
Traceable
Verifiable

RED SUN Inc.

21

Validation Review - 1
A formal and focused meeting in which a small group of
stakeholders evaluate requirements documentation to find
errors and improve quality.
Purpose:
To detect errors and inconsistencies in requirements, to
ensure that the requirements adequately represent user
needs, to reduce the costs associated with correcting
implementation defects that originate in requirements,
and to increase BIM quality.
To educate project teams about requirements and ensure
that their understanding is consistent with user needs.
Get BIM Engineers who work on requirements
development to focus more on those parts with highest
risk or ambiguity.

RED SUN Inc.

22

Validation Review - 2
Formal review processes are defined for a group
of stakeholders where each is assigned to specific
roles with specific tasks to be performed during a
specific time.
Reviewer will:
Follow the defined process.
Use checklists, standards, and guides.
Focus on a portion of requirements document.
Provide feedback.
Verify corrective actions are addressed.
Defects found early in the process are easier to fix
and less costly than defects found later.
RED SUN Inc.

23

Review Roles
Moderator: Manages and coordinates the entire process.
Authors: Requirements engineers who produce the
document being reviewed.
Reviewers: Stakeholders who review the document.
Recorder: Documents information on forms.
Requirements validation reviews:
Select a portion of the document to be reviewed.
Identify stakeholders who will act as reviewers.
Plan and explain roles, responsibilities and authorities.
Preparation by using checklists to analyze document.
Conduct review by following the defined process to
provide feedback in a scheduled meeting.
Revise requirements document based on feedback.
RED SUN Inc.

24

Validation Review Process

Select a portion of
requirements
document to review.
Identify a small group
of stakeholders
to conduct review.
Plan the review.
Schedule meeting.

Prepare for the

review meeting.

Conduct the review.

Provide feedback.

Checklists

RED SUN Inc.

Revise the
requirements
document
based on feedback.

25

Checklist
Checklists are a means to remind reviewers of
important things to look for.
Checklists are lists of critical information content
that a deliverable should contain or typical defects
to look for (duplicated information, missing
information, unclear information etc.).
Checklists contains items deemed critical either
by the individuals who need the deliverable to do
their job or by feedback from previous work
efforts that have been harmed by not including it.
Checklists can be used throughout the
development cycle.
RED SUN Inc.

26

General Checklist - 1
Are the requirements complete?
Are all requirements uniquely identifiable?
Are the requirements clearly and appropriately prioritized?
Are the requirements consistent? (no contradictions)
Does the set of requirements adequately address all
appropriate exception conditions?
Does the set of requirements adequately address boundary
conditions?
Are the requirements feasible? (a solution exists)
Can the requirements be implemented within known
constraints?
Are the requirements sufficient? (i.e., they could be sent to
BIM development team and have a reasonable probability
of implementing the product that was desired)

RED SUN Inc.

27

General Checklist - 2
Are requirements explicitly stated?
Do the set of requirements meet the stakeholders needs?
Are all cross-references to other requirements correct?
Have functional and non-functional requirements been
considered?
Is the requirement precise and unambiguous?
Is the requirement stated simply as possible?
Is the requirement testable/verifiable?
Is the requirement correct?
Is the requirement in scope? (i.e., the system will be
considered incomplete if even one requirement is left out)
Is the statement of the requirement expressed only in terms
of what and why, rather than how?

RED SUN Inc.

28

General Checklist - 3
Does the requirement meet a stated stakeholder need?
Is the requirement both necessary and sufficient?
Is the requirement understandable without having to
analyze the meaning of words?
Does the requirement have a unique interpretation?
Do all stakeholders interpret the requirement in the same
way?
Is the requirement redundant?
Does the requirement conflict with others?
Does the requirement contain errors of fact?
Is it physically possible to meet the requirement using
existing technologies?
Can the requirement be met within the approved schedule
and budget?

RED SUN Inc.

29

Specific Checklist - 1
Do requirements exhibit a clear distinction between
functions and data?
Do requirements define all the information to be displayed
to users?
Do requirements address system and user response to error
conditions?
Is each requirement stated clearly, concisely, and
unambiguously?
Is each requirement testable?
Are there ambiguous or implied requirements?
Are there conflicting requirements?
Are there areas not addressed in the SRS that need to be?
Are performance requirements (such as response time, data
storage requirements) stated?

RED SUN Inc.

30

Specific Checklist - 2
If the requirements involve complex decision chains, are
they expressed in a form that facilitates comprehens ion
(i .e., decision tables, decision trees, etc.)?
Have requirements for performing BIM upgrades been
specified?
Are there requirements that contain an unnecessary level of
design detail?
Have the real-time constraints been specified in sufficient
detail?
Has the precision and accuracy of calculations been
specified?
Is it possible to develop a thorough set of tests based on the
information contained in the SRS? If not, what information
is missing?
Have Assumptions and Dependencies been clearly stated?
Does the document contain all the information called out in
the outline for the SRS?

RED SUN Inc.

31

User Acceptance Test - 1

Definition:
Specific test cases used to decide whether to
accept a delivered BIM product or system
by the user.
Each acceptance test is a Black box test (test
case written without regard to implementation)
that represents system inputs and expected
outputs that the final system is designed to
operate.
Acceptance tests should be written earlier after
a requirements document is complete and
revised with more details as the development
progresses.
Acceptance tests can also be used to validate
BIM requirements specification.
RED SUN Inc.

32

User Acceptance Test - 2

Benefits:
Allow test activities to begin independently of design and
implementation.
Guide users to more explicitly describe how they expect
the BIM to work.
Ensures that tests exist to prove the system conforms to
users expectations.
Provides a concrete depiction of the data necessary for
users to accept the final system.
Provides a basis for developing user manuals and
training materials.
Establish criteria on the users ability to accomplish
specific tasks and the systems ability to meet certain
quality attributes.
Facilitate more user involvement.
RED SUN Inc.

33

User Acceptance Test - 3

Severity
Level

Definition

Critical, it will be impossible to continue with testing

or to accept the system because of this error.

Major, testing can continue but the system cannot

be deployed with this problem.

Medium, testing can continue and the system is

likely to be deployed with some departure from the
agreed-upon business functionality.

Minor, testing and deployment can progress. The

problem should be corrected but will not impact
business functionality.

Cosmetic, errors such as color, fonts, and displays

that are less than desirable and can be corrected at
some future time.

RED SUN Inc.

34

Verification & Validation

Business
Requirements

Business
Results
Validate

User Acceptance
Tests

User Requirements

BIM
Requirements

BIM Design

BIM Functions

Verify

Verify

Verify

System Tests

Integration
Tests

Functional Tests

Unit Tests
Model
RED SUN Inc.

35

Summary
Requirements are critical to the success of the project.
Before starting the development project, it is essential that
BIM Engineers must define what to build, ensuring that it is
necessary to meet the stakeholders needs.
BIM Engineers must review requirements documents and
begin to write acceptance tests with test cases and test
scripts (conceptual tests) to help identify incomplete,
incorrect and unclear requirements.
As requirements are developing, BIM Engineers must verify
requirements with stakeholders to ensure they meet the
needs of users (build BIM correctly).
As requirements are completed and documented, BIM
Engineers must validate the goals and objectives with
stakeholders to ensure that they meet in the project (build
the correct BIM).

RED SUN Inc.

36

Why Do Requirements?
10 Top Reasons for Not Doing Requirements:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

We have already started writing Model, and we don't want to

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

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

RED SUN Inc.

37

Questions & Answers

RED SUN Inc.

38