2. Enterprise Knowledgebases
Knowledgebases are used to store information that is used between projects. Optimally,
enterprise libraries should be maintained by business unit; however they may also be
maintained by business analyst as they define project requirements. The four enterprise
libraries are explained below.
A business rule is a compact statement about some aspect of the business • Business Rules
Business that serves as a constraint of what must or must not be done. Rules are
organized in rule books and expressed using simple, clear language. They
Rules should be accessible by all interested parties such as business process
owners, business analysts, technical architects and so on.
A business process is the set of steps a business performs to create value for • Business Process
Business customers. A process consists of three components: inputs, activities, and
Processes outputs.
Stakeholder profiles are used to describe categories of individuals involved in • Stakeholder
project such as the sponsor, customers, end-users, business subject matter Profile
Stakeholder experts, and people involved in the design, development, implementation
Profiles and support of the solution.
Products are used to document the products and services that the • Product or Service
organization delivers to the customer. This category can also be used for ITIL Description
Products V3 Service Descriptions. In this case, the product and all of its projects with • Product Feature
associated requirements become a Service Design Package. Roadmap
1
3. Three Level of Requirements
(Generally recognized)
Represent the high level objectives of the • Business Objectives
organization. Business requirements describe • Project Vision and Scope
Business why the system is being developed, • Project Constraints
measurable business benefits that align with • Business Process Design
Requirements the organization’s vision, and any constraints • Business Rules
that have been imposed on the project.
User requirements describe what the users • Stakeholder Needs
need to perform their tasks. They bridge the • Needs from Document Review
gap between business requirements and • Business Rule Constraints
User what the developers will build (system • Use Cases
Requirements requirements). • User Stories
• Scenario
System requirements describe how the • Functional requirements
business processes will be automated • Supplemental requirements
(functional requirements) and the attributes • Test Cases
System and constraints of the environment where • Requirement Bundles
Requirements the system will operate (supplemental
requirements).
2
4. Requirements Overview
Business Requirements (Objectives and Constraints)
Business
Process Analysis and User Requirements (Needs)
Design
Organizational Change
Software
& Training
Requirements
Requirements
Organizational Design
Systems Analysis and
and Change
Design
Management
3
5. Avoiding Confusion
Many people seem to confuse the three because the work requirement is used in all three. Ee use
the following terms in the Requirements Excellence Framework:
Business Objectives and Constraints
Business Objective - Reduce delinquent accounts to 10% or less, within three months.
Project Constraint - The software must be delivered by March 31st, 2012.
Technical Constraint – The system must utilize the Oracle Database to comply with our
standards.
Needs
User Need – As an accounting clerk, I need the ability to cancel transactions.
Requirements
Functional Requirement - System shall permit users to cancel transactions with an audit trail.
Supplemental Requirement –-The system must be available 24 hours a day from Monday to
Saturday.
A statement about “how” the solution will work as opposed to “what” it is intended to do should
be captured in the Design Document. The statement below is not a requirement.
“The Location shall be selected from a drop-down list”
4
6. Business Rules
Project
Feature
Impact
Process Category Rule Book Scope
Statement
Business rules are maintained
separate from requirements. They Functional Supplemental
Requirement Requirement
are organized by rule book for
various functional topics such
vacation and holiday leave, travel,
customer service, etc.). Each rule Business Rule Related Rules
book has a rule book owner. Rule
books are ideally maintained by the
business. Rules may be linked to
requirements.
5
7. Business Processes
Process Category Feature
Project
Impact
Process Group
Scope
Business Process Statement
Process
Impact
Activity Functional Supplemental
Requirement Requirement
The process structure is organized using During Process Analysis, impacts on Since software is used to
APQC’s Process Classification Structure existing business processes are provide automated support
(PCF). The PCF was developed by APQC identified and documented . for a business process, it is
and its member organizations as an open Depending on the size of the essential to understand how
standard to facilitate improvement project, AS IS and TO BE business the process is going to work
through process management and process models may be created or before defining software
benchmarking, regardless of industry, size, updated. The business process requirements.
or geography. The PCF organizes operating impacts are later used in the
and management processes into 12 Project Scope Activity to define
enterprise-level categories, including scope statements which are used
process groups and over 1,000 processes to elicit needs from Stakeholders 6
and associated activities. and specify requirements.
8. Stakeholders
Stakeholder Stakeholder Project
Profile Contact Contact
Product
Product Project
Stakeholder Stakeholder
Project
Project Stakeholders and Project Stakeholder contacts are
identified during Stakeholder Analysis. Feature
Stakeholder Needs are identified during Elicitation through a Impact
variety of elicitation techniques such as web forms, Stakeholder Need
interviews, observations and group discussion. They are
captured using patterns and organized by Product
Stakeholder and cope Statement.
Scope
User Stories are a special type of need often used on Agile User Story
Statement
projects. They are normally in the form of As…, I want to… so
that I can ….. Stakeholders are linked to user stories via the As
a … clause of the user story.
Use Case
Use Cases are developed by the analyst during Analysis to
gain a better understanding of the sequence of events and 7
user involvement.
9. Products
Project
Product
Feature Scope
Feature
Impact Statement
Functional Supplemental
Requirement Requirement
Products may be implemented many ways depending on the needs of the organization.
For example, products could be applications, ITIL Services, or products or services sold
to external customers. A project can impact one or many products. Defining scope
statements depends on having feature (Product) and Process impacts identified and
documented.
8
10. Projects
The Project, the Project Vision and Project Constraints
Stakeholders that are defined during the Project Vision activity.
are impacted by the
project are Project Vision
identified during Project
the Stakeholder Stakeholder
Project
Analysis activity
Project Constraints
Impact on the
product portfolio. Feature Impact
These are identified
during the Project
Business Objectives
Scope activity SMART business objectives are
Scope documented during the Business
Process Impact
Business process Statement Objectives activity.
impact that are
identified and
documented during
Process Analysis. Requirement
Functional Supplemental
Requirement Requirement Management. Plan
Functional requirements,
supplemental requirements and
The Requirement Management Plan
related business rules are
Related Rules defines the approach and set of
developed during the
tasks to complete Requirements
Specification activity, Development and Management
activities.
9
11. Requirements Development
Scope Statements are defined in the Project Scope activity and Process Impacts are
used to elicit needs and specify requirements. identified during Process
Process Analysis and used to
Impact define scope statements.
Project Stakeholders are identified Scope
during Stakeholder Analysis Impacts on products and
and used to define stakeholder Statement Feature services are identified during
needs and user stories. Project Impact Project Scope and are used to
stakeholders are also used as actors create scope statements.
in Use Cases.
Supplemental Supplemental Requirements
Stakeholder Need
Requirement are created during
Specification.
Project
User Story
Stakeholder Functional Functional Requirements
are created during
Requirement
Use Case Specification.
Stakeholder Needs are User Stories are a special type Use Cases are
Related Rules
identified during Elicitation of need which are created developed by the analyst
through a variety of during Elicitation. during Analysis to gain a Related Rules are identified
elicitation techniques such as better understanding of during Specification and
web forms, interviews, the sequence of events linked to a requirement.
observations and group and user involvement.
discussion.
Note that Requirements Development is an iterative and incremental activity. Generally Elicitation,
Analysis, Specification, and Validation go on concurrently. 10
12. Requirement Management
Functional and Supplemental
Stakeholder Need User Story Use Case Requirements are grouped into
bundles. Associated User Stories, Use
Cases Stakeholder Needs, and Related
Related Rules Business Rules are included by
Functional Supplemental reference.
Requirement Requirement Lifecycle Events are identified based on
the type of requirements in the bundle.
Lifecycle Events include such things as
Validation, Design Reviews, User
Bundles Acceptance Testing, Code Inspections,
Sprint Plans, etc.
Lifecycle Event
Change Requests Defects
After a bundle has Participants Test Scenarios Validations Requirement defects
been baselined, all are recorded and
changes, additions, Project Stakeholders Validations are performed tracked to ensure they
and deletions are participate in Test Cases to confirm such things as: are resolved.
controlled and lifecycle events to • needs are addressed,
tracked. perform tests and User Acceptance Tests • developers understand
validations of the are defined to ensure the requirements, and
requirements. that the solution meets • there is sufficient budget
the defined to build the solution.
requirements.
11