Академический Документы
Профессиональный Документы
Культура Документы
Elicitation
Analysis
Specification
Clarify
Validation
Re-Write
Definitions
Requirements Analysis
The techniques of deciding which features are
appropriate for the product based on
stakeholders needs.
To effectively analyze requirements, BIM
Engineers need to understand, define and verify
the requirements from the stakeholders view
so they can prioritize their needs before allocating
requirements to BIM.
Requirements elicited from stakeholders must be
complete and clear to validate later.
* IEEE Standard 610.12 IEEE Glossary of BIM Engineering Terminology
RED SUN Inc
Requirements Analysis
The process of analyzing the stakeholders needs
to prepare the definitions of system and BIM
requirements.
The process of transforming business needs into
system descriptions with performance parameters
and partitioning them into subsystems where
allocation to hardware and BIM can take place.
Since stakeholders and developers may have
different views and expressions, to facilitate
better understanding, BIM Engineers should use
abstract descriptions that are easy to
understand and interpret.
RED SUN Inc
Different Views
Objective: To define what the system will do
Stakeholders
Developers
Qualitative definition
Interpretation to be expected
All requests must be met
Requirements are evolving
On going process
Schedule driven
System must work
Functional definition
Precise, clear
Complete
Frozen, baseline
Must complete within time
Task driven
Good if not perfect system
Communication Is Essential
Requirements Engineering is not only a
process of gathering and discovering
requirements, but also a process of
facilitating effective communication of
these requirements among different
stakeholders.
The way in which requirements are
analyzed and documented plays an
important role in ensuring that they can be
read, analyzed, rewritten, and validated.
Requirements Engineering is an iterative
process.
RED SUN Inc
Requirements Analysis
Requirements analysis results in requirements
models.
Requirements models are user requirements
represented by diagrams, structured text (lists,
tables, matrices) or a combination.
Requirements analysis also focuses on trade-offs
among requirements to make decisions about
their relative importance to support
prioritization.
BIM Engineers are responsible to analyze all
requirements and collaborate with stakeholders to
prioritize their needs.
Requirements analysis is an iterative process.
RED SUN Inc
(Gather Requirements)
Preliminary
Requirements
Review with
Stakeholders
Assign
Quality Attributes
Identify
Candidate
Requirements
Verify Scope
of System
Establish
Quality
Attributed
Requirements
Draft
Baselined
Requirements
Specification
(Document Requirements)
10
Model Result:
Actor Table.
RED SUN Inc
11
Model results:
Glossary
Context diagram
Relationship model (Business model)
Data model & Data dictionary
RED SUN Inc
12
Model results:
Event-response table
State diagram
13
Model results:
Business policies
Business rules
14
Models results:
Process map
Use case
Data flow diagram
15
Product
Vision
Detailed level
Stakeholder
Categories
Actor Table
Prototypes
Glossary
Data Model
Data Dictionary
When?
Events
Response
State Diagrams
Why?
Business
Policies
Business Rules
Decision Tree
How?
Process Map
Use cases
Scenarios, Stories
Product
What?
High levels
Who?
Scope
BIM
Business
Requirements
Requirements
Requirements Roadmap
16
Business Rules
Every organization operates according to an
extensive set of business rules such as policies,
laws, regulations, standards, procedures,
techniques, processes etc.
A business rule is a statement that defines or
constrains some aspects of the business, it is
intended to assert structure and to control or
influence the behavior of the business.
Business rules describe the operations, definitions
and constraints that apply to an organization in
achieving its goals by setting up a set of policies,
procedures, and standard practices to be applied
consistently across organizations.
RED SUN Inc
17
Example
Regulations
Policies
Example:
Business Rules
Procedures
Standards
Processes
18
Actor Table
An A ctor table identifies a ll users in terms of their
roles and responsibilities.
By identifying all actors in the same place, it may
detect missing users and determine who or what
needs to interact with the system, what roles they
play and their responsibilities.
Each actor in the table is likely to initiate at least
one use case and help uncover issues involving
where (at which physical location) to roll out the
system and in which order.
A user may have multiple roles and an actor can
represent multiple people .
For example: A Manager can be the reviewer, producer
and approver. Producers can be played by several
people.
19
Roles, Responsibilities
Job Title
Planner
Project Manager
Estimator
Project Manager
Designer
Developer
Modelr
Developer
Tester
Developer
Reviewer
SQA
Sponsor
Manager
User
Customer
20
21
Context Diagram
A Context Diagram represents all external
entities that may interact with a system. It is the
highest level view of a system, showing the
system as a whole with its input and output
from/to external factors.
The Context Diagram is NOT a Data Flow Diagram
because it has only one function representing the
entire system or its scope.
The Context Diagram provides a visual model of
the proposed system and the outside entities that
interface with the system. It is easily understood
by the stakeholders and is used to reach
agreement on the scope of the project.
RED SUN Inc
22
Context Diagram
Bank Teller
Customer
Deposit Money
Response to requests
Customer
Withdraw Money
Customer
Bank
Open Account
Response to requests
Manage the Bank
Bank Teller
Customer
Check Balance
Bank Owner
23
24
Data Model - 1
A data model or Entity Relationship Diagram
(ERD) descr ibes how data is represented and
accessed. It formally defines data elements and
their relationships.
Business rules define how things are done and
how data models are structured. Changes in
business can lead to large changes in computer
systems and interfaces.
If relationships among data are not identified,
they can lead to replication of data, data
structure, functionality, and duplication in
development and maintenance.
If data models for different systems are different.
It will require complex interfaces between
systems which are costly.
25
Data Model - 2
If data structure is not standardized, data
cannot be shared electronically with
customers and suppliers.
Data models can:
Illustrate the structure of the data after
business rules have been enforced.
Eliminate redundant data and complex data
structure.
Specify rules to maintain data integrity.
Help answer questions on which data users
need to access and save.
RED SUN Inc
26
Process Model
Process
Data Model
Process
Data
Data
Data
Data
Logical Model
Design
Pseudo
Model
Requirements
Document
Physical Model
Application
programs
Data
Structure
27
28
29
Cash
Inquiries
Withdrawals
Deposits
Account Details
Account Information
Account Information
30
State Diagram
State diagrams are used to describe the behavior
of a system. State diagrams can describe the
possible states of an object as events occur.
A model of system behavior composed of a finite
number of states, transitions between those
states and actions.
Each diagram usually represents objects of a
single class and tracks the different states of its
objects through the system.
31
State
Entry action
Turn Off
Machine
On
Off
Machine On
Machine Off
Turn On
Machine
32
33
Summary
Since no single view of requirements provides a
complete understanding, BIM Engineers need a
combination of textual and visual requirements
representations to create a full picture of the
proposed system.
Modeling and diagrams communicate certain
information more efficiency than text can. A
picture is worth a thousand words.
However, do not assume stakeholders know how
to read models, so BIM Engineers must explain
the purpose and notations of each model and ask
stakeholders to verify them.
RED SUN Inc
34
35