Your SlideShare is downloading. ×
0
Requirement pro data structures
Requirement pro data structures
Requirement pro data structures
Requirement pro data structures
Requirement pro data structures
Requirement pro data structures
Requirement pro data structures
Requirement pro data structures
Requirement pro data structures
Requirement pro data structures
Requirement pro data structures
Requirement pro data structures
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Requirement pro data structures

2,137

Published on

Requirement pro data structures

Requirement pro data structures

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,137
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
107
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Requirement Excellence Framework™RequirementPro™ Architecture www.EnfocusSolutions.com
  • 2. Enterprise KnowledgebasesKnowledgebases are used to store information that is used between projects. Optimally, enterprise librariesshould be maintained by business unit; however they may also be maintained by business analyst as theydefine 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 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 the business process owner, business analysts, technical architects and so on. A business process is the the set of steps a business performs to create value • Business Process Business for customers. A process consists of three components: inputs, activities, and Processes outputs. Stakeholder profiles are used to describe categories of individuals involved in • Stakeholder Stakeholder the project such as the sponsor, customers, end-users, business subject Profile matter experts, and people involved in the design, development, Profiles implementation 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 can also be used for ITIL V3 Description Products 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. The business requirements • Project Vision and Scope Business describes why the system is being done, • Project Constraints measurable business benefits that align with • Business Process DesignRequirements 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 the business requirements and • Business Rule Constraints User what the developers will build (system • Use CasesRequirements 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 BundlesRequirements the system will operate (supplemental requirements). 2
  • 4. Requirements Overview Business Requirements (Objectives and Constraints) BusinessProcess Analysis and User Requirements (Needs) Design Organizational Change Software & Training Requirements Requirements Organizational Design Systems Analysis and and Change Design Management Confidential - Not for External Distribution 3
  • 5. Avoiding ConfusionMany 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, 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 statements about “how” the solution will work as opposed to “what” it is intended to do should becaptured in Design Document. The statement below is not a requirement. “The Location shall be selected from a drop-down list” Confidential - Not for External Distribution 4
  • 6. Business Rules Project Feature Impact Process Category Rule Book Scope StatementBusiness rules are maintained separatefrom requirements. They are organized Functional Supplementalby rule book for various functional topics Requirement Requirementsuch vacation and holiday leave, travel,customer service, etc). Each rule bookhas a rule book owner. Rule books areideally maintained by the business. Business Rule Related RulesRules may be linked to requirements. Confidential - Not for External Distribution 5
  • 7. Business Processes Process Category Feature Project Impact Process Group Scope Business Process Statement Process Impact Activity Functional Supplemental Requirement RequirementThe process structure is organized using During Process Analysis, impacts on Since software is used to provideAPQC’s Process Classification Structure (PCF). existing business processes from are automated support for a businessThe PCF was developed by APQC and its identified and documented . process, it is essential to understandmember organizations as an open standard to Depending on the size of the how the process is going to workfacilitate improvement through process project, AS IS and TO BE business before defining softwaremanagement and benchmarking, regardless of process models may need to be requirements.industry, size, or geography. The PCF organizes created or updated. The businessoperating and management processes into 12 process impacts are later used in theenterprise-level categories, including process Project Scope Activity to definegroups and over 1,000 processes and scope statements which are used toassociated activities. elicit needs from Stakeholders and specify requirements. 6
  • 8. Stakeholders Stakeholder Stakeholder Project Profile Contact Contact Product Product Project Stakeholder Stakeholder ProjectProject Stakeholders and Project Stakeholder contacts are identifiedduring Stakeholder Analysis. Feature Impact Stakeholder Needs are identified during Elicitation through a variety of elicitation techniques such as web forms, interviews, observations and Stakeholder Need 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 projects. They User Story are normally in the form of As…, I want to… so that I can ….. Stakeholders Statement 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 Use Case of the sequence of events and user involvement. 7
  • 9. Products Project Product Feature Scope Feature Impact Statement Functional Supplemental Requirement RequirementProducts may be implemented many ways depending on the needs of the organization. For example, products couldbe applications, ITIL Services, or products or services sold to external customers. A project can impact one or manyproducts. Defining scope statements depends on having feature (Product) and Process impacts identified anddocumented. Confidential - Not for External Distribution 8
  • 10. Projects The Project, the Project Vision and Project Constraints are defined during the Project Vision activity.Stakeholders thatare impacted by theproject are Project Visionidentified during Projectthe Stakeholder Stakeholder ProjectAnalysis 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 ImpactBusiness process Statement Objectives activity.impact that areidentified anddocumented duringProcess Analysis. Requirement Functional Supplemental Requirement Requirement Management. Plan Functional requirements, supplemental The Requirement Management Plan requirements and related Related Rules defines the approach and set of business rules are developed tasks to complete Requirements during the 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 Impacts on products andduring Stakeholder Analysis Statement Feature services are identified duringand used to define stakeholder Impact Project Scope and are used toneeds and user stories. Project create scope statements.stakeholders are also used as actorsin Use Cases. Supplemental Supplemental Requirements Stakeholder Need Requirement are created during Specification.. Project User StoryStakeholder Functional Functional Requirements are created during Requirement Use Case Specification..Stakeholder Needs are User Stories are a special type Use Cases are Related Rulesidentified during Elicitation of need which are created developed by the analystthrough a variety of during Elicitation. during Analysis to gain a Related Rules are identifiedelicitation techniques such as better understanding of during Specification andweb 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 EventChange Requests DefectsAfter a bundle has Participants Test Scenarios Validations Requirement defectsbeen baselined, all are recorded andchanges, additions, Project Stakeholders Validations are performed tracked to ensure theyand 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

×