1. How does a Requirements Package Vary from Project to Project?
Angie Perris, PMP
Vice President, Business Development
B2T Training, L.L.C.

2. Agenda Planning for a Complete Requirements Package
Characteristics of Projects
Requirements Components that are Necessary
Example Projects and Their Requirements

3. Categories of Requirements
Business requirements
Defined by BAs
The “What”:
Detailed descriptions of the business data, business processes, business rules and interactions needed to accomplish the business mission.
Functional requirements
The “How”:
Functional requirements describe how software should work and what the software will “look like” to the end user.
Technical requirements
Defined by IT
Detailed descriptions of how the software will be built and where the data will be stored.

4. Techniques for Documenting Requirements
Database design
Very detailed
Data requirements (entities, attributes, relationships)
System Use Case Description
Essential Process Description
Screen or report prototype
Business Use Case Description
Glossary
Screen Storyboard prototype
Process Maps
Workflow diagram
Workflow diagram
Business Use Case Description
Decomposition diagram
Workflow diagram
Workflow diagram
Broad, high-level
Context-level DFD
Use Case diagram
Business Requirements
Functional
Requirements

5. B2T Requirements Package

6. Not Every Project Needs Every Requirement Type
Do I really have to review a 60-page requirements document just to get one field added to a screen?!!
Subject Matter Expert

7. Building the Appropriate Requirements Package
At the start of the project the Project Manager and Business Analyst should decide which components of the requirements package are appropriate.
Several basic questions must be answered about the project to determine this.

8. Questions that Must Be Answered
Will the project result in a new software application?
Why are we doing this project?
Will the project result in changes to our organizational structure?
Will the project require a change to the existing software?
Will we develop the software in-house, outsource, or purchase?
How complex is the business?

9. Why are These Questions Important?
Does the request involve a change to existing software or procedures?
If so, is the existing software well documented?
Is the existing software maintained in-house or by a vendor?
Are the existing procedures well documented?
Are the requirements from the original project or other projects available for re-use?
When changes are made to existing software or procedures, the BA can take advantage of existing requirements or documentation.

10. Why are These Questions Important?
Does the request involve a brand new software application or procedure?
Number of departments or organizations impacted
Number of software users
Number of software interfaces (adjacent systems that surround work)
Is this a new business process?
If not, how is it currently performed?
Is a vendor package being considered?
Are there influences from outside bodies that affect the software application (legal, professional standards, etc.)?
A new business process or automated process requires complete, thorough analysis and detailed requirements.

11. Requirements “Rules-of-Thumb”
New software?
All sections
Large/critical/complex?
More detail
Project stakeholders in different geographical locations?
Greater risk - more formal

12. Requirements “Rules-of-Thumb”
Multiple viewpoints?
Resolve conflicting requirements early
Document all driving viewpoints
What is the audience like?
Formal/casual style, vocabulary, details
Combining multiple organizations?
Organizational workflows
Risky?
Apply techniques to alleviate potential problems +

13. Requirements “Rules-of-Thumb”
Time-to-market critical?
Prioritize deliverables
Timebox requirements techniques
COTS?
Perform gap analysis against requirements
SMEs confused?
Use techniques that your Subject Matter Experts understand

14. Requirements “Rules-of-Thumb”
Functional details missing?
Gain initial, high-level agreement, then build detail
Previous requirements available?
Re-use
Similar project?
Remember lessons learned
Review early and often
Frequently invite project stakeholders to validate requirements

15. Which Sections of the Package Are Needed?
Requirements Section Description
Project Initiation
Project approach or methodology
Project scope
Statement of purpose
Objectives
Problems/opportunities
Business risks
Assumptions
Viewpoint(s)
External interactions
High level processes
Items not in scope
Glossary
Required for medium to large size projects
Always required
There should always be at least 1
As needed
Should be considered on medium to large size projects
There should always be at least one business process
Should be clearly stated to avoid scope confusion

16. Which Sections of the Package Are Needed?
Requirements Section Description
There should always be at least one business process
There will always be at least one entity used by the project
There will always be at least one attribute used by the project
Required when there is more than one entity
As needed
Business Requirements
Business processes
Data requirements
Entities
Attributes
Relationships
Additional business rules

17. Which Sections of the Package Are Needed?
Requirements Section Description
Functional Requirements
User classes/actors
Design area scope
Workflows
System functionality
User interface
Performance requirements
Security requirements
Quality requirements
Required if project involves new users or new software
Required for medium to large size projects
Useful for manual procedural changes
Useful for analyzing current processes
Useful for designing software usage
Required if project involves any online screens
Required if project involves any online screens or reports
Required for medium to large projects
Required for process improvement efforts
Required for new software development
Required for mission critical projects

18. Defining Requirements for Different Types of Projects
Define the different sizes of projects; factor in risk
Define the different types of projects
Define the deliverables and tasks that are linked to the size and type of projects.
Update matrix with new types of projects and technology
S: Small: <120 hours, <10 users; 1-2 reports/screens, low risk
M: Medium: 120-1,040 hours, users, medium risk
L: Large: >1,040 hours, >100 users; significant logic changes for new business processes, high risk
B: Bugs – Fixes only, no new features
N: New Build – Fresh sheet of paper
T: New Technology
E: Enhancement – new features added to existing product
P: Purchase – COTS
I: Infrastructure – Process improvement, etc.

19. Example Change request:
“We need to have a place for customers to type in their address a second time to make sure that it is correct. Many of our messages are coming back because the address is wrong.”
Existing screen:

20. Example

21. Example

22. Example

23. Conclusion
Project Manager and the Business Analyst must plan the requirements deliverables at the beginning of the project, based on project’s unique characteristics and risk.
The key requirement components are always necessary.
Don’t hesitate to re-visit these decisions as the analysis gets started:
You may learn something that is not anticipated.
Use a change control process.

24. Questions?