requirement pro data structures

Requirement Excellence Framework™

RequirementPro™ Architecture

www.EnfocusSolutions.com

2

A business rule is a compact statement about some aspect of the business that serves as constraint of what must or must not be done. Rules are organized in rule books and expressed using simple, clear language. They should be accessible by all interested parties such as the business process owner, business analysts, technical architects and so on.

• Business Rules

A business process is the the set of steps a business performs to create value for customers. A process consists of three components: inputs, activities, and outputs.

• Business Process

Stakeholder profiles are used to describe categories of individuals involved in the project such as the sponsor, customers, end-users, business subject matter experts, and people involved in the design, development, implementation and support of the solution.

• Stakeholder Profile

Products are used to document the products and services that the organization delivers to the customer. This can also be used for ITIL V3 Service Descriptions. In this case, the product and all of its projects with associated requirements become a Service Design Package.

• Product or Service Description

• Product Feature Roadmap

Enterprise Knowledgebases

BusinessRules

BusinessProcesses

StakeholderProfiles

Products

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.

3

Represent the high level objectives of the organization. The business requirements describes why the system is being done, measurable business benefits that align with the organization’s vision, and any constraints that have been imposed on the project.

• Business Objectives• Project Vision and Scope• Project Constraints• Business Process Design• Business Rules

User requirements describe what the users need to perform their tasks. They bridge the gap between the business requirements and what the developers will build (system requirements).

• Stakeholder Needs• Needs from Document Review• Business Rule Constraints• Use Cases• User Stories• Scenario

System requirements describe how the business processes will be automated (functional requirements) and the attributes and constraints of the environment where the system will operate (supplemental requirements).

• Functional requirements• Supplemental requirements• Test Cases• Requirement Bundles

Three Level of Requirements (Generally recognized)

BusinessRequirements

UserRequirements

SystemRequirements

Confidential - Not for External Distribution

4

Requirements Overview

Business Requirements (Objectives and Constraints)

BusinessProcess Analysis and

Design

Systems Analysis and Design

Organizational Design and Change

Management

SoftwareRequirements

Organizational Change& Training

Requirements

User Requirements (Needs)


5

Avoiding Confusion

Many people seem to confuse the three because the work requirement is used in all three.In the Requirements Excellence Framework, we use the following termsBusiness 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, 2012Technical Constraint – The system must utilize the Oracle Database to comply with our standards.

NeedsUser Need – As an accounting clerk, I need the ability to cancel transactions.

RequirementsFunctional 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 statements about “how” the solution will work as opposed to “what” it is intended to do should be captured in Design Document. The statement below is not a requirement.

“The Location shall be selected from a drop-down list”


6

Business Rules

Rule Book

Business Rule Related Rules

Project

ScopeStatement

FunctionalRequirement

SupplementalRequirement

Process Category

Business rules are maintained separate from requirements. They are organized by rule book for various functional topics such vacation and holiday leave, travel, customer service, etc). Each rule book has a rule book owner. Rule books are ideally maintained by the business. Rules may be linked to requirements.

FeatureImpact

7

Business Processes

Process Category

Process Group

Process

Activity

Business ProcessImpact

Project

ScopeStatement



The process structure is organized using APQC’s Process Classification Structure (PCF). The PCF was developed by APQC and its member organizations as an open standard to facilitate improvement through process management and benchmarking, regardless of industry, size, or geography. The PCF organizes operating and management processes into 12 enterprise-level categories, including process groups and over 1,000 processes andassociated activities.

During Process Analysis, impacts on existing business processes from are identified and documented . Depending on the size of the project, AS IS and TO BE business process models may need to be created or updated. The business process impacts are later used in the Project Scope Activity to define scope statements which are used to elicit needs from Stakeholders and specify requirements.

Since software is used to provide automated support for a business process, it is essential to understand how the process is going to work before defining software requirements.

FeatureImpact

8

Stakeholders

Product

ProductStakeholder

StakeholderProfile

ProjectProjectStakeholder

ProjectContact

ScopeStatement

Stakeholder Need

User Story

Use Case

Stakeholder Needs are identified during Elicitation through a variety of elicitation techniques such as web forms, interviews, observations and group discussion. They are captured using patterns and organized by Product Stakeholder and cope Statement.

User Stories are a special type of need often used on Agile 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 Cases are developed by the analyst during Analysis to gain a better understanding of the sequence of events and user involvement.

Project Stakeholders and Project Stakeholder contacts are identified during Stakeholder Analysis.

StakeholderContact

FeatureImpact


9

Products

Product

Feature ScopeStatement

Project



FeatureImpact

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.

10

Projects

ScopeStatement

ProjectProject Vision

Business Objectives



Process Impact

Feature Impact

Project Constraints

ProjectStakeholder

Related Rules

Stakeholders that are impacted by the project are identified during the Stakeholder Analysis activity

Impact on the product portfolio. These are identified during the Project Scope activity

Business process impact that are identified and documented during Process Analysis.

Functional requirements, supplemental requirements and related business rules are developed during the Specification activity,

The Project, the Project Vision and Project Constraints are defined during the Project Vision activity.

SMART business objectives are documented during the Business Objectives activity.

RequirementManagement. Plan

The Requirement Management Plandefines the approach and set of tasks to complete Requirements Development and Management activities.

11

Requirements Development

Related Rules

ScopeStatement



ProjectStakeholder

FeatureImpact

Process Impact

Stakeholder Need

User Story

Use Case

Project Stakeholders are identified during Stakeholder Analysisand used to define stakeholder needs and user stories. Project stakeholders are also used as actors in Use Cases.

Process Impacts are identified during Process Analysis and used to define scope statements.

Impacts on products and services are identified during Project Scope and are used to create scope statements.

Scope Statements are defined in the Project Scope activity and used to elicit needs and specify requirements.

Related Rules are identified during Specification and linked to a requirement.

Functional Requirements are created during Specification..

Stakeholder Needs are identified during Elicitation through a variety of elicitation techniques such as web forms, interviews, observations and group discussion.

User Stories are a special type of need which are created during Elicitation.

Supplemental Requirements are created during Specification..

Use Cases are developed by the analyst during Analysis to gain a better understanding of the sequence of events and user involvement.

Note that Requirements Development is an iterative and incremental activity. Generally Elicitation, Analysis, Specification, and Validation go on concurrently.

12

Requirement Management

Bundles

Lifecycle EventChange Requests Defects

Participants ValidationsTest Scenarios

Test Cases



Related Rules

Stakeholder Need User Story Use CaseFunctional and Supplemental Requirements are grouped into bundles. Associated User Stories, Use Cases Stakeholder Needs, and Related Business Rules are included by reference.

Lifecycle Events are identified based on the type of requirements in the bundle. Lifecycle Events include such things as Validation, Design Reviews, User Acceptance Testing, Code Inspections, Sprint Plans etc.

After a bundle has been baselined, all changes, additions, and deletions are controlled and tracked.

Project StakeholdersParticipate in lifecycle events to perform tests and validations of the requirements.

User Acceptance Tests are defined to ensure that the solution meets the defined requirements.

Validations are performed to confirm such things as: • needs are addressed, • developers understand

the requirements, and • there is sufficient budget

to build the solution.

Requirement defects are recorded and tracked to ensure they are resolved.