Hubspotmarketingtransformationfinal 110330085430 Phpapp02 110404122224 Phpapp02
Requirementsdevelopment 120207165817-phpapp02
-
Upload
oginni-olumide -
Category
Business
-
view
288 -
download
1
Transcript of Requirementsdevelopment 120207165817-phpapp02
2
Requirements Development
Related Rules
ScopeStatement
FunctionalRequirement
SupplementalRequirement
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.
3
Elicitation is the process of gathering and documenting needs from stakeholders, identifying other requirements sources, and applying techniques specified in the RMP to gather the information and document the needs
• Stakeholder Needs• Document Review• User Stories• Use Cases
Analysis is the process of analyzing the data gathered during elicitation, resolving conflicts, analyzing business rules, documenting assumptions, constraints, and dependencies, and working with stakeholders to establish initial priorities.
• Stakeholder Needs Analysis
• Document Review Analysis
• Business Rules Analysis
Specification is the process of defining functional and supplemental text based requirements and supporting them with various visualization techniques such as process models, UML diagrams, wireframes, white boarding, etc.
• Functional requirements• Supplemental
requirements• Visualizations
Validation is the process of reviewing the requirement specifications and associated visualizations with the stakeholders for quality characteristics such as completeness, correctness, clarity, practicality, value, etc.
• Validated requirement bundle
Requirements Development
Elicitation
Analysis
Specification
Validation
Requirements development is the process of studying stakeholder needs to arrive at as set of complete and prioritized requirements that address strategy, people, process, and technology issues related to the project.
4
Strategy, People, Process, and Technology
Strategy People Process Technology• Business Objectives• Project Vision• Project Scope• Project Constraints
• Stakeholder Analysis • Process Analysis • Technical Constraints
• Organizational Change Needs
• Business Process Needs
• Related Business Rules
• Use Cases• User Stories
• Organizational Change and Training Requirements
• Business Process Requirements
• Functional Requirements
• Supplemental Requirements
5
Elicitation
• The optimal method for eliciting needs is for stakeholders to document their own needs in their own words using the Stakeholder Portal™. The Business Analyst can assist the Stakeholders by providing examples and guidance.
• The Stakeholder Portal™ may also be used to capture the needs of a group in the event that a workshop or series of workshops is used.
• In the event that workshops or interview are used, analysts need to recognize that customers will not be able to express all their needs in a single workshop or interview.
• In addition to system needs, business process and organizational change needs should also be captured. Failure to do so will most likely result in suboptimal solution.
• Elicitation requires multiple cycles of refinement, clarifications, and adjustment as participants move from high level concepts to specific details perhaps through a series of releases or iterations.
• Related documents, notes, or graphics should be gathered and stored as attachments for further reference. These attachments can be linked to needs in the Stakeholder Portal.™
6
Elicitation Techniques
Documentation Review
Review relevant documents such as regulations, internal
audit reports
Stakeholder PortalStakeholders record their needs directly using the
Stakeholder Portal
Use CasesBusiness Analysts create use cases for major activities and
review with Stakeholders
WorkshopsSessions are held to identify and document user needs
ObservationBusiness Analysts document
needs by observing work performed
InterviewsKey stakeholders are
interviewed to ascertain their needs
Stakeholder AnalysisNeeds are identified when
conducting the Stakeholder Analysis
BrainstormingNeeds are captured in a
brainstorming session using a Mind Map.
Business Process Analysis
Needs are identified when defining the “To Be”
business process model
Confidential - Not for External Distribution
7
Elicitation DocumentationStakeholder Needs User Stories Use Cases
Needs are documented in words the stakeholder understands using predefined patterns included in the Stakeholder Portal™
• General Capability• Reports and Queries• Compliance• Security and Controls• Performance• Safety• Operating Environment• Documentation• User Interface• Organizational Change• Business Process Changes
Needs are documented using a User Story based on the pattern below
As a type of user
I need to do this activity
So that I can achieve this benefit
Business Analyst define use cases to document the work of the stakeholder and how he interacts with the system.
A use case is a description of steps or actions between a user (or "actor") and a software system which allows the user to perform a meaningful task. The user or actor might be a person or something more abstract, such as an external software system or manual process.
AttachmentsRelated meeting notes, documents, graphics, etc. should be gathered and linked tothe artifacts above.
8
Standish Group Research
What factors cause projects to become challenged?
1. Lack of User Input 2. Incomplete Requirements &
Specifications 3. Changing Requirements & Specifications
Why are projects impaired and ultimately cancelled?
4. Incomplete Requirements 5. Lack of User Involvement 6. Lack of Resources 7. Unrealistic Expectations 8. Lack of Executive Support 9. Changing Requirements & Specifications
What is needed to achieve project success?
1. User Involvement 2. Executive Management Support3. Clear Statement of
Requirements 4. Proper Planning 5. Realistic Expectations 6. Smaller Project Milestones 7. Competent Staff 8. Ownership 9. Clear Vision & Objectives 10. Hard-Working, Focused Staff
Source: Standish Chaos Report
The Requirement Excellence Framework fully or partially addresses most of these issues. Good requirements and user participation will have a major impact on the success of projects.
9
Requirements Elicitation Risks
• Insufficient user involvement leads to unacceptable products• Creeping user requirements contribute to overruns and
degrade product quality• Ambiguous requirements lead to ill-spent time and rework• Gold-plating by developers and users adds unnecessary
features• Minimal specifications lead to missing key requirements• Overlooking the needs of certain user classes leads to
dissatisfied customers• Incompletely defined requirements make accurate project
planning and tracking impossible
10
Requirements Planning Activities
Documenting the Project Vision• Gaining an understanding of the business strategy and why the project is
being undertakenDefining Business Objectives• Defining clear measurable business objectivesBusiness Process Analysis• Identifying what business processes will be impacted• Gaining a full understanding of how the business process will work after the
project has been implemented• Determining how the new or modified software will support the business
processProject Scope DefinitionStakeholder Analysis• Identifying the expected Stakeholders and user classes for the product
11
Requirements Development Tasks
Elicitation• Eliciting needs from individuals who represent each StakeholderAnalysis• Analyzing the information received from users• Understanding actual user tasks and objectives• Partitioning system-level requirements into major subsystems.• Understanding the relative importance of quality attributes• Negotiating implementation prioritiesSpecification• Translating the collected user needs into written specifications and models• Reviewing the requirements specifications Understanding the relative importance of
quality attributes• Negotiating implementation priorities• Reviewing the requirements specificationsValidation
12
Requirements Management Activities
• Defining the requirements baseline• Reviewing proposed requirements • Incorporating approved requirements changes into the
project in a controlled way• Keeping projects plans current with the requirements• Negotiating new commitments based on the estimated
impact of changed requirements• Tracing individual requirements to their corresponding
designs, source code, and test cases• Tracking requirements status and change activity
throughout the project.
13
Stakeholder Needs
Project Scope Record
• General Capability• Reports and Queries
• Compliance• Security and Controls• Performance• Safety• Operating Environment• Documentation• User Interface• Organizational Change• Business Process Changes
Stakeholder NeedsPatterns
StakeholderProfile
• Stakeholder Needs are captured from the point of view of a stakeholder
• Stakeholder needs are organized by Project Scope Records
• Stakeholder needs are captured using predefined patterns
14
User Stories
• A user story is a short description of customer’s need. User Stories are commonly used in agile software methodologies and frameworks such as Extreme Programming or Scrum as a way of gathering requirements.
• Whenever possible, users should write their own stories; otherwise they can be written by business analyst on behalf of the user.
• User stories are generally expressed using the template below.
“As a <specific user//role>” I what <desired feature/issue that needs to be solved>, so that <benefit from implementing the feature>”+ Test Cases (Acceptance Criteria)
15
Use Cases
What is a use case?• A use case is a description of how users will perform tasks on your System.• A use case includes two main parts:
– the steps a user will take to accomplish a particular task on your site– the way the Web site should respond to a user's actions
• A use case begins with a user's goal and ends when that goal is fulfilled.What does a use case describe?• A use case describes a sequence of interactions between a user and a
system, without specifying the user interface.• Each use case captures:
– The actor (who is using the System?)– The interaction (what does the user want to do?)– The goal (what is the user's goal?)
16
User Stories
• Independent• Negotiable• Valuable• Estimable• Sized Correctly• Testable
User stories should be written using INVEST.
17
Other Sources of Requirements
• Existing Process Improvements– Help Desk trouble tickets– Trainers and consultants– Help desk and support team– Customer suggestions and complaints– Internal Audit Reports
• Process Improvement– Process Benchmarking– Six Sigma Studies
• Competition– Competitive products– Analyst Reports
• Other
18
Analysis
Analysis is the process of analyzing the data gathered during elicitation, resolving conflicts, analyzing business rules, documenting assumptions, constraints, and dependencies, and working with stakeholders to establish initial priorities.• Analysis is not a linear process; it is done concurrently with
the elicitation. Business analysts continually monitor needs from stakeholders to ensure understanding and to work with stakeholders that have difficulty in expressing their needs.
• Based on the business process analysis, business analyst identify and document business rules that will affect the system.
19
Stakeholder Needs Analysis
• Stakeholder needs are analyzed by the requirements analyst using the requirements analysis dashboard
• The needs are tagged in variety ways depending on organizational requirements.
• Tags can be used for– Return on investment– Must Have, Nice to Have– High, Medium and Low Priorities– Architectural category
20
Business Rules Analysis
• Business Rules Analysis is the process of determining what business rules apply to the requirements.
• The business rules are maintained by rule book in a knowledgebase
• Applicable business rules are linked to requirements during analysis and specification
21
Business Process Analysis
• Review the “As Is” and “To Be” business analysis and identify actions that need to be done to accomplish the business objectives, achieve the project vision, and deliver the project scope.
Confidential - Not for External Distribution
22
Specification
Specification is the process of defining functional and supplemental text based requirements and supporting them with various visualization techniques such as process models, UML diagrams, wireframes, white boarding, etc.
Confidential - Not for External Distribution
23
How Much Detail do You Need?
• Extensive customer Involvement• Developers have considerable
domain• Experience• Precedents are available• Package solution will be used
• Outsourced development• Team is geographically dispersed• Testing will be based on requirements• Accurate estimates are needed• Requirements traceability is needed
Less Detail More Detail
• As usual in software development, the answer to this question is, “It depends.”• The central question to consider when deciding how detailed to make the requirements is:
Who do you want to have making decisions about requirements details and when?• If you’re willing to defer many of the ultimate decisions about product capabilities and
characteristics to the developers, then you don’t need to include as much detail in the requirements documentation.
• However, if you want to ensure that you get exactly what you expect, you need more comprehensive specifications.
• Don’t expect that even the best written requirements specification can – or should – replace human dialogue.
Confidential - Not for External Distribution
24
Requirements vs. DesignWhy undertake the project?
(business objectives)
What the user will be able to do with the product? (Stakeholder Needs, Use Cases, User Stories)
What the developer builds? (Functional and Supplemental Requirements)
Systems components and how they fit together? (System Architecture, Component Architecture, UI Architecture)
Systems components and how they fit together? (Class Diagram, Database Design, User Interface Design)
How the components will be implemented? (Algorithms, UI Controls)
DecreasingAbstraction
Confidential - Not for External Distribution
25
Writing Clear Requirements
Write in Active VoiceWith active voice, the reader doesn’t have to deduce what entity is doing what. It’s easier for readers to understand explicit and precisely stated requirements that are written in active voice. Fewer assumptions are needed to interpret the requirement.Example:• Passive (weak): When the output state changes, it is logged in the event log.• Active (strong): When the output state changes, the system shall record the new state in
the event log.
Avoid Ambiguity• An ambiguous requirement is one that the reader can interpret in more than one way,
or one that different readers can interpret in multiple ways.
Don’t Design the System• If we supply too much detail, we start to design the system prematurely. Danger signs
include: name of components, materials, software objects/procedures, database fields,
26
Writing Clear Requirements
Avoid Negation• Before: All users with three or more
accounts should not be migrated.• After: The system shall migrate only users
having fewer than three accounts.• Before: The security module will not allow
access by users who do not have a valid userid and password.
• After: The security module shall only allow access by users who have a valid userid and password.
Watch for Omissions• Before: The system shall display the user’s
defined bookmarks in a collapsible hierarchical tree structure.
• After: The system shall display the user’s defined bookmarks in a collapsible and expandable hierarchical tree structure.
Be Careful of Boundary Values• Before: 1. If the amount of the cash
refund is less than $50, the system shall open the cash register drawer.
If the amount of the cash refund is more than $50 and the user is not a supervisor, the system shall display a message: “Call a supervisor for this transaction.”
• After: 1. If the amount of the cash refund is less than or equal to $50, the system shall open the cash register drawer.
If the amount of the cash refund is more than $50 and the user is not a supervisor, the system shall display a message: “Call a supervisor for this transaction.”
27
Writing Clear Requirements
Watch synonyms and Near Synonyms• use terms consistently• define terms in a glossaryBe Careful of Similar Sounding Words• “Special Day caller tunes (default)
will take priority over all configured individual caller settings that a customer has selected. However, if an individual has been assigned a Special Day caller tune for the same date, this will overwrite the Special Day caller tune.”
Pronouns• make the antecedents crystal clear
Be Careful with Vague Adverbs• Provide a reasonably predictable end-user
experience.• Offer significantly better download times.• Optimize upload and download to perform
quickly.• Downloading should complete in
approximately 15 minutes.• Exposing information appropriately…• Generally incurs a “per unit” cost…• To enable remedial action to be initiated in a
timely manner…• …as expediently as possible…• Occasionally (not very frequently) there will
be an error condition…• others: easily, ideally, instantaneously,
normally, optionally, periodically, rapidly, typically, usually
28
Writing Clear Requirements
i.e. and e.g.• i.e. = “that is”; e.g. =
“for example”• “The system shall use
single-letter color codes, i.e., R for red, G for green, and B for blue.”
• better to use English
Do not Use Vague Terms• user-friendly, modern, robust, efficient,
versatile, flexible• efficient, flexible, robust, high-
performance• seamless, transparent, graceful• improved, state-of-the-art, superior• rapid, easy, simple, intuitive,• minimize, maximize, optimize• few, several, some, many, approximately• sufficient, adequate, at least• reasonable, where appropriate, to the
extent possible,• if necessary, optionally• etc., including, and/or• as possible
29
Writing Clear Requirements
Don’t Express Possibilities• May, might, should, ought, could,
perhaps, probablyAvoid Wishful Thinking• 100% reliable• Safe• Handle all unexpected failures• Please all users• Run on all platforms• Never failDon’t Speculate• Usually• Generally• Often• Normally• Typically
Avoid Conjunctions– And, or, with, also
Don’t ramble• Example- Provided that the
designated input signals from the specified devices are received in the correct order where the system is able to differentiate the designators, the output signal shall comply with the required framework of section 3.1.5 to indicate desired input state.
Confidential - Not for External Distribution
30
Anatomy of a Good Requirement
User Category Who benefits from the requirement
The Call Center operator
Expected Result Desirable state for the user to reach
shall be able to see the customer record
Mechanism to Test Mechanism to allow a test to be written against the requirement.
within 2 seconds from the time the call is received.
Confidential - Not for External Distribution
31
Quality Attributes for Requirements
• Requirement Bundles– Complete - nothing is missing; nothing should say “to be determined”– Consistent requirements should not conflict with other requirements
• Individual Requirements– Correct - accurately states a customer or external need– Clear - has only one possible meaning– Feasible - can be implemented within known constraints– Modifiable - can be easily changed, with history, when necessary– Necessary - documents something customers really need– Prioritized - ranked as to importance of inclusion in product– Traceable - can be linked to system requirements, and to designs, code, and
tests– Verifiable - correct implementation can be determined by testing,
inspection, analysis, or demonstration
32
Prioritization Scale
• Prioritization scale is based on Stephen R. Covey, The 7 Habits of Highly Effective People, Simon & Schuster, 1989
Urgent Not Urgent
ImportantHigh Priority
Must be included in the next release
Medium PriorityMust be included but cant
wait for later release
Not Important
Low ValueDo not add sufficient value for
to include in the project
Low PriorityNice to have if you have the
budget to include
33
Requirement Visualization
Requirement Visualization
WhiteboardingStoryboards UML Models
Photos and Videos
Business Process
Diagrams
Illustrated Concept Diagrams
Enfocus Requirement Suite integrates with many requirement visualization tools and technologies. With the Suite, output from these tools can be related to requirements and use cases, as well as other artifacts. Requirement Coach provides guidance for integrating these tools.
Wireframes
Confidential - Not for External Distribution
34
Supplemental Requirements
• Performance• Archival and Storage• Security and Controls• Usability• Look and Feel• Access Control• Training• Business Process and Workflow• Infrastructure• Documentation• Business Continuity• System Connectivity• Interface Transaction