1. Requirements Analysis INCOSE Systems Engineering Boot Camp
Dr. Ralph R. Young
Director of Software Engineering
Systems and Process Engineering
Defense Enterprise Solutions
Northrop Grumman Information Technology
(703)

2. INCOSE Systems Engineering Boot Camp
Things I’ve Noticed From My Requirements Engineering Experience
Information and guidance concerning effective requirements practices is available but is not applied by most Project Managers.
Although the requirements engineering process is a full system life cycle process, a lot of the issues and problems are created in the requirements gathering activities.
Therefore, in my opinion, we can save a lot of time by addressing this area more effectively. Industry data supports this view.
Further, doing a better job in requirements elicitation reduces rework downstream. Rework = 45% of total project effort industry wide.
The requirements are often unknowable at the inception of many systems and projects. We need to recognize this and deal with it.
Tools don’t obviate the need for people, a requirements process (in all situations), effective practices, and formal training.
Customer involvement throughout the project is essential.
An incremental development approach works best when the requirements are evolving and changing.

3. Practices, Methods, Techniques, and Tools That May Be New, Different, and Especially Important
Create or tailor a requirements process.
Use effective requirements practices, tailored as needed to the size and scope of the project, e.g.,:
a “joint team;”
defining the “real requirements;”
iterating the requirements and architecture repeatedly;
achieving effective communication; and
use your requirements process and practice continuous improvement.
Consider having an organizational requirements working group.
Consider time-boxes to set limits on prototype iterations.
Consider Requirements Based Product Development (RBPD) utilizing an effective automated requirements tool.
Have an organizational center of excellence to enable and empower your organization, e.g.:
requirements and architecture working groups
a process improvement group
organizational “process owners”
an electronic process asset library to share and reuse artifacts

4. Establishing the partnership: User / Establishing the Partnership: User/Customer Responsibilities
Know what is needed
Know why it is needed
Provide information to help others know what you know
Document your assumptions
Prioritize requirements
Be reasonable
Be timely

5. Developer and Customer Tasks
Provisional
& final
acceptance
Acceptance,
integration &
verification
Informing the
enterprise
Detailed
design &
component
development
Storing and using
knowledge from
previous projects
Developer
work
Architectural
System
design
Amount of effort
User
requirements
requirements
Customer work
Defining
Defining what
Optimizing
Deciding
Linking
Qualifying
Verifying
results
the system
the cost-
on potential
deliverables
the
& validating
for users
must do
benefits
changes
to requirements
design
the product

7. Goals of Good Requirements Practitioners
Identify incorrect assumptions
Ensure consistency
Increase compliance
Reduce misunderstandings between organizations and individuals
Improve the responsiveness of suppliers
Improve the satisfaction of all customers
Write good requirements

8. Characteristics of Effective Requirements Analysts
An attitude of continuous improvement and commitment to meet customers real needs.
Good listener, communicator, and writer.
Commitment to learning, applying, and using improved practices and methods, and to project success.
Proactive in engaging co-workers, project management, customers, and users.
Expert knowledge of requirements engineering and requirements practices.
Ability to estimate the resources and time required to accomplish technical work.
Takes responsibility for her/his views, attitudes, relationships, and actions.
Maintains focus on keeping the main thing the main thing.
Persevering.
Maintains a good knowledge of evolving technology and how it can be applied to meet customer needs.
Sets achievable goals and meets them.
Desires to "make a difference" in his/her professional work.
Good facilitation skills.
Ability to "think outside the box" to provide creative approaches that might not occur to people who are close to the problem and the legacy system.

9. What Drives Requirements
Regulations
Higher Level
Specifications
Standards
What Drives
Requirements
Customer & User
needs & expectations
Constraints
costs
schedules
technical
viability
Existing
systems &
processes

10. Before You Write Requirements You Write Requirements
Perform the up-front process
Assemble and educate the team
Define documents
Define outline (checklist)
Plan for change

11. Up-front Process Determine drivers
Understand customer needs and environment
Understand and document the scope of your project
Define external interfaces
Define system components
Define specifications outline

12. Types of Requirements Errors

13. Criteria for a Good Requirement
Each individual requirement should be:
Correct – Technically and legally possible
Complete – Express a whole idea or statement
Clear – Unambiguous and not confusing
Consistent – Not in conflict with other requirements
Verifiable – Can be determined to meet the requirement
Traceable – Uniquely identified and can be tracked
Feasible – Accomplished within cost and schedule
Modular – Can be changed without excessive impact
Design independent – Does not pose a specific implementation solution

14. Effective Requirements Practices
Commit to the approach.
Establish and utilize a Joint Team to be responsible for the requirements.
Define the real customer needs.
Use a requirements process
and continually improve it.
Iterate the system requirements
and the system architecture repeatedly.
Use a mechanism to maintain project
communication between and among all engineering groups throughout the development effort.
Select familiar methods and maintain a
set of work products that collectively
comprise the current requirements specification.
Perform requirements verification and validation.
Provide an effective mechanism to accommodate changes in requirements
during system life cycle development.
Perform the development
effort using known familiar proven industry,
organizational, and project best practices.

15. The Value of an Organizational Requirements Working Group
Allows the organization to benefit from the experience of its projects and the expertise of key staff members
Seeds the organization with persons who share a common body of knowledge and who have come into consensus on key topics
Members provide a resource to the remainder of the organization
Facilitates use of the developed knowledge and artifacts for use in winning new business (proposals, lead marketing briefings, etc.)
Encourages a common way of doing things; supports repeatability and reuse
Encourages and facilitates selection of appropriate methods and tools as well as their deployment and implementation
Encourages us to measure the effectiveness of the process and the benefits of institutionalization
Allows participation in industry leading-edge efforts (such as transition packages, AKA “Jump Start Kits”
Consider initiating one in your organization

16. The CMMI SE/SW High Level Summary
1 -
Initial
Heroes
2 -
Managed
Project management
Configuration Management Requirements Mgmt
Project Monitoring & Control Project Planning
Supplier Agreement Management Measurement & Analysis
Process & Product Quality Assurance
3 -
Defined
Engineering process
Decision Analysis & Resolution Risk Management
Integrated Project Management Validation
Organizational Training Verification
Organizational Process Definition Product Integration
Organizational Process Focus Technical Solution
Requirements Development
4 -
Quantitatively Managed
Product & process
quality
Quantitative Project Management
Organizational Process Performance
5 - Optimizing
Continuous process
improvement
Causal Analysis & Resolution
Organizational Innovation & Deployment
Level
Focus
Process Areas
Result
Productivity
& Quality
Risk