Best Practices of Requirements Collection
Accurate Requirements form the most essential part of the formula for
successful software product development.
This article explains why and describes the best practices of writing
accurate requirements.
A Fortune 100 company embarked on a project to design and build a
sophisticated software package that it would ultimately deploy to its offices
throughout the world. Two years and about $10 million later, the field offices
refused to use the software because it didn't do what it was intended to do.
Instead of helping to streamline an important business process, the software
actually hindered it.
Sounds a similar story? Based on several surveys by various groups, there
are some stark findings:
- The Standish group reports that over 80% of projects are unsuccessful
either because they are over budget, late, missing function, or a
combination. (http://www.standishgroup.com/sample_research/chaos_1994_1.php)
- 53 percent of projects cost 189 percent of their original estimate.
- Average schedule overruns may be as high as 100%
- Over 40% to 60% of defects in software are caused by poor requirements
definition.
- About One-Quarter of all projects are cancelled.
- Customers do not use 20% of their product features.
These are some of the many findings that do not speak highly of successes
of software development projects. Based on our experience of over fifteen
products, and learning from the several surveys and research, we have
identified that the most critical factor of successful software product
development is the right requirements documentation. Poor requirements are the biggest
problem that end up increasing the budgeted engineering cost and not matching
with the expected quality.
If we look little deeper, and see why poor requirements cause all the
havoc:
- Impact on Design and Architecture: Incorrect or incomplete understanding of the
current and future requirements will not enable the architects to design
the right architecture and design that can take care of current and
immediate future needs.
- Increased Dev Iterations: If the development team does not have the complete information,
there will be far too many iterations and cycles around requirements
understanding.
- Impact on Quality: If
the development team makes too many incorrect assumptions because of lack
of clarity, it may arise in a lot of iterations in the later half of
development, when the product managers realize the gap due to incorrect
assumptions.
- Reduced Testablity: The
test engineers do not have the complete picture to write correct test
plans and test cases if the requirements are not properly communicated to
the test team in the right manner.
As these issues point out, accurate and complete documentation of
requirements is very important. In addition, presenting them in a form that
will communicate the complete and accurate picture to the development team is
equally important. If the development team cannot visualize the end product
completely, there will always be a gap between the actual vision and the
software developed and the development will go into several iterations trying
to bridge that gap.
We have learnt a lot of lessons on requirements process from our vast
software product experience. In addition, we have done extensive research on
the best practices followed at the top software product companies in the world. Our experience and research has helped us to
define the types of requirements needed for capturing all aspects of software.
They are:
a. Business Vision and Business Requirements - "Why" requirements. These capture the high
level objectives of the organization or customer requesting the system or the
product. They can be considered as "why we are doing this"
requirements and should capture the fundamental reason for product existence.
b. Functional Requirements - Functional requirements can be considered as the
"What" requirements. These capture the functionality that must be
built into the system to satisfy business requirements. Use Cases are
great way to document functional requirements. A use case defines a goal-oriented set of interactions
between external actors and the system under consideration.
c. Non-Functional Requirements: They are the "How" or "How Well"
requirements. They capture the technology specific and -ility requirements of
the system like compatibility, usability, usability, performance, reliability
etc.
d. UI Prototypes - UI prototyping helps in reducing risk, decreased system size and
complexity, and reduced requirements change. The UI prototypes must be
validated by the (beta) customers before they can be frozen. We have found them
to be the most effective way of communicating requirements to the development
team. UI prototypes/screenshots provide a great visualization tool for both
development and test engineers to understand the exact software flow and they
are much more effective in designing classes and test cases.
We recommend "Requirements Scrubbing" after they are documented.
It is a process of carefully examining the requirements for unnecessary or
overly complex requirements, which are then removed. The idea is to eliminate
all non-essential requirements, making each requirement as simple as possible,
and substituting with cheaper options whenever possible.
Finally, how would you ensure that you have covered all aspects of
requirements through functional and non-functional requirements? We have
prepared exhaustive checklists that will help you to make sure that your
requirements are ready to be published to the development team.
Functional Requirements Checklist:
a. Are the requirements complete ?
b. Are all the requirements uniquely identifiable?
c. Are the requirements clearly and appropriately prioritized?
d. Are the requirements consistent? ( no internal
contradictions)
e. Does the set of requirements adequately address all
appropriate exception conditions?
f. Does the set of requirements adequately addresses boundary
conditions?
g. Are the requirements feasible? (solution to the
set of requirements exists)
h. Can the requirements be implemented within known constraints?
i.
Are the
requirements sufficient?
j. Are inverse requirements explicitly stated?
k. Are these the simplest set of requirements that
meets the stake-holder's needs?
l.
Are all the cross-references
to other requirements correct?
m. Is each requirement testable/verifiable?
n. Ensure that each requirement needs to be a solution instead
of being stake-holder's statement.
o. The requirements need to be in customer's language using
customer's terminology.
Non Functional Requirements Checklist:
a. Performance - performance requirements of the application -- Response time or latency
requirements; Throughput requirements; data volume requirements ( input,
stored, output), Peak or short-term load requirements.
b. Platform support - which Operating systems, prerequisite software and hardware
requirements.
c. Licensing - licensing scheme of the product and other OEM/external licensing
requirements.
d. Internationalization - what locales/languages is this software going to be built for now and
future.
e. Integration requirements - How do you want third party applications to integrate
with your application to enable more usage scenarios and sales partnership
opportunities? How do you want to integrate with third party applications for
similar benefits?
f. Setup - How should the product be deployed? You must consider install, uninstall,
repair and upgrade scenarios.
g. Security - What is the security and safety model for your application? Consider
authentication, authorization and secure data transfer. You must consider both
application and platform (windows) security.
h. Configurations - Are the Supported Configurations specified? Are the Compatibility
requirements specified ( backwards, other applications, etc.)
i.
Usability - Are the usability requirements specified? Are the look
and feel requirements specified? ( Color schemes, standards etc.)
j. Operational - Are any operational constraints or requirements specified? ( the user
must be able to operate the system using ski gloves etc)
k. Reliability - Are the reliability requirements specified? Are the availability
requirements specified? Are the serviceability requirements
specified? Are the robustness requirements specified?