Friday 7 December 2012

Software Requirements - Part 1

In the 1995 the Standish Group did a very revealing research called The Chaos Report.
The research shows a staggering 31.1% of projects will be cancelled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates.
Lack of user input and incomplete requirements and specifications were listed as the main causes of project failures. Errors made during the requirements stage account for 40 to 60 % of all defects found in a software project (Davis 1993; Leffingwell 1997)

In the last two decades new methodologies has been created and adopted but these are still fundamental problems in software companies. This is why I decided to study more about the subject.

After an attentive analysis I decided to read the following book:


In this post, and subsequent posts I would like to summarise the book and describe what I found most interesting.

One thing that I like about the book is that it is completely independent by a specific methodology. This allows me to create a big picture of the topic before digging into specifics.

Everything start from a question.

What is a software requirement?

There is no universal definition of what a requirement is.

There is a formal definition from IEEE but in few words we can say that:
Requirements are descriptions of how a system should behave or of a system property or attribute. Requirements may also be a constraint on the development process of the system.
The absence of a unique definition means that you shouldn't assume that all your project stakeholders share a common notion of what requirements are and that it is good to define your specific definition.

Are there multiple types of requirements?

Yes and it is very important to understand the differences between them:
  • Business Requirements
    • High-Level objective
    • Explain why the organisation is implementing the system.
    • Usually stored in a "Vision and scope" document
  • User Requirements
    • User goals or tasks that the users must be able to perform with the product
    • Must align with the business requirements
  • Functional Requirements
    • Software functionality that the developers must build into the product to enable users to accomplish their tasks, thereby satisfying the business requirements
  • System Requirements
    • Top level requirements for a product that contains multiple subsystems
  • Non functional Requirements
    • Usability, portability, integrity, efficiency, robustness, ...
    • Also called: Quality Attributes
In addition, there are other important terms that are frequently used in the context of software requirements:
  • Business Rules
    • Corporate policies, government regulations, industry standards, ...
    • There are usually requirements associated to business rules
  • Feature
    • A set of logically related functional requirements that provides a capability to the user and enables the satisfaction of a business objective
  • Software Requirements Specification (SRS) 
    • Describes as fully as necessary the expected behaviour of the software system. Do not include design or implementation details, project planning or testing info.

What do you mean by Requirements Engineering?

From Wikipedia:
Requirements engineering (RE) is a systems and software engineering process which covers all of the activities involved in discovering, documenting and maintaining a set of requirements for a computer-based system
It is possible to distinguish between two types of Requirements Engineering:
  • Requirements Development
    • Elicitation
      • Identifying the product's expected user classes
      • Eliciting need from individuals who represent each user class
      • Understanding user tasks and goals and the business objectives with which those tasks align
    • Analysis
      • Analysing the information received from users to distinguish their task goals from functional requirements, non functional requirements, business rules, suggested solutions, and extraneous information
      • Understanding the relative importance of quality attributes
      • Negotiating implementation priorities
    • Specification
      • Allocating portions of the top-level requirements to software components defined in the system architecture
      • Translating the collected user needs into written requirements specifications and models
    • Validation
      • Reviewing the documented requirements to ensure a common understanding of the users' stated requirements and to correct any problems before the development group accepts them
  • Requirements Management
    • Establishing and maintaining an agreement with the customer on the requirements for the software project
    • Defining the requirements baseline (snapshot in time representing the currently agreed-upon body of requirements for a specific release)
    • Reviewing proposed requirements changes and evaluating the likely impact of each change before approving it
    • Incorporating approved requirements changes into the project in a controlled way
    • Keeping project plans current with the requirements
    • Negotiating new commitments based on the estimated impact of requirements changes
    • Tracing individual requirements to their corresponding designs
    • Tracking requirements status and change activity throughout the project
The boundary between the two requirements processes can be described by the following image:


It is interesting to show the graph about the relative cost to correct a requirement defect depending on when it is discovered.



What are the benefits from a High-Quality Requirements Process?
  • Better understanding of the user community or market
  • Generates enthusiasm for the product and builds customer loyalty
  • Fewer requirements defects
  • Reducing development rework during the late development stages and throughout the lengthy maintenance period
  • Fewer unnecessary features
  • Lower enhancement costs
  • Faster development
  • Fewer miscommunications
  • Reduced scope creep
  • Reduced project chaos
  • More accurate system-testing estimates
  • Higher customer and team member satisfaction
Let me finish this post with some theoretical but extremely important information.

What are the characteristics of Excellent Requirements?
  • Complete
    • Must fully describe the functionality to be delivered
    • Must contain all the information necessary for the developer to design and implement that bit of functionality
  • Correct
    • Must accurately describe the functionality to be built.
  • Feasible
    • It must be possible to implement each requirement within the known capabilities and limitations of the system and its operating environment.
    • Incremental development approaches and proof-of-concept prototypes are ways to evaluate requirement feasibility
  • Necessary
    • Should document a capability that the customers really need or one that's required for conformance to an external system requirement or standard
  • Prioritised
  • Unambiguous
  • Verifiable
The entire set of requirements must be:
  • Complete
    • No requirements should be absent.
  • Consistent
    • No conflicts with other requirements
  • Modifiable
    • Maintain history of changes made to each requirement
  • Traceable
    • Can be linked backward to its origin and forward to the design elements and source code that implement it and to the test cases
    • Each requirement must be uniquely labelled and appear only once
This list of characteristics is obviously desirable but almost never fully achievable in practise. 

The best way to tell whether your requirements have these desired attributes is to have several project stakeholders carefully review the software requirements specification document.


No comments:

Post a Comment

What you think about this post? I really appreciate your constructive feedback (positive and negative) and I am looking forward to start a discussion with you on this topic.