Software Requirements - Part 2

This is the second part of the following book summary.

Previous posts:

• Software Requirements - Part 1

Let's continue our discussion with new questions.

Who is a customer?

An individual or organization who derives either direct or indirect benefit from a product.

It is clear that customer development relationship is extremely critical to software project success.

Who is a user?

What? Is not the same as the customer? Well, not necessary!

So, what is the difference between Users and Customers?

Users use your product. Customers buy it.

Your users may be the customers and this is often the case for commercial software development. However, it is important to remember that this is not always true.

Who are the stakeholders?

From Wikipedia:

Stakeholders are anyone who has an interest in the project. Project stakeholders are individuals and organizations that are actively involved in the project, or whose interests may be affected as a result of project execution or project completion.

All stakeholders share a common objective:

Build a successful software product that provides adequate business value and rewards to all stakeholders

Excellent software products are the result of a well-executed design based on excellent requirements. High-quality requirements result from effective communication and collaboration between developers and customers - a partnership.

A collaborative effort can work only when all parties involved know what they need to be successful and when they understand and respect what their collaborators need to be successful.

What are the rights of software customers?

1. Expect analysts to speak your language
2. Expect analysts to learn about your business and your objectives for the system
3. Expect analysts to structure the information you present during requirements elicitation into a written software requirements specification
4. Have analysts explain all work products created from the requirements process
5. Expect analysts and developers to treat you with respect and to maintain a collaborative and professional attitude throughout your interactions
6. Have analysts and developers provide ideas and alternatives both for your requirements and for implementation of the product
7. Describe characteristics of the product that will make it easy and enjoyable to use.
8. Be given opportunity to adjust your requirements to permit reuse of existing software components
9. Receive good-faith estimates of the costs, impacts, and trade-offs when you request a change in the requirements
10. Receive a system that meets your functional and quality needs, to the extent that those needs have been communicated to the developers and agreed upon

What are the duties of software customers?

1. Educate analysts and developers about your business and define business jargon. The intent is not to transform analysts into domain expert, but to help them understand your problems and objectives.
2. Spend the time that it takes to provide requirements, clarify them, and iteratively flesh them out
3. Be specific and precise when providing input about the system's requirements.
4. Make timely decisions about requirements when requested to do so
5. Respect a developer's assessment of the cost and feasibility of requirements
6. In collaboration with the developers, set priorities for functional requirements, system features, or use cases.
7. Review requirements documents and evaluate prototypes.
8. Communicate changes to the requirements as soon as you know about them.
9. Follow the development organization's process for requesting requirements changes.
10. Respect the processes the analysts use for requirements engineering.

What is the concept of Signing Off on the requirements document?

Many organizations use it as the make of customer approval of those requirements. 

The sign means:

I agree that this document represents our best understanding of the requirements for this project today and that the system described will satisfy our needs. I agree to make future changes in this baseline through he project's defined change process. I realize that approved changes might require us to renegotiate the cost, resource, and schedule commitments for this project.

This definition is extremely important because it contains an important thing. Everyone agree that it's impossible to know all the requirements early in the project and that requirements will undoubtedly change over time. This is why the signing process should never used as a weapon.

The most important thing of the sign-off ritual is the concept of establishing a Baseline of the requirements agreement, a snapshot of it at a point in time.

What software development methodology to use?

The author of the book explicitly say that being a strong supporter of a specific software development methodology is not usually desirable.  It is by far, more important to identify and apply industry best practices rather than devising or purchasing a whole-cloth solution.

Even if you do adopt a commercial methodology, adapt it to best suit your needs and augment its components with other effective practices from your tool-kit.

I don't have a strong experience but I have to say that I entirely agree with him. This seems the most pragmatic way to approach the problem.

So, what are good practices for Requirements Engineering?

Some generic practices are:

• Train requirements analysts
• Educate user representatives and managers about requirements
• Train developers in application domain concepts
• Create a project glossary
• Document the steps your organization follows to elicit, analyse, specify and validate requirements.

Let me remember the typical steps of requirements engineering:

• Requirements Development
• Requirements Elicitation
• Requirements Analysis
• Requirements Specification
• Requirements Validation
• Requirements Management

Let's see what are the good practices for each type of requirements engineering.

What are good practices for Requirements Elicitation?

• Write a vision and scope document
• Identify user classes and their characteristics
• Select a product champion for each user class
• Establish focus groups of typical users
• Work with user representatives to identify use cases
• Identify system events and responses
• Hold facilitated elicitation workshops
• Observe users performing their jobs

What are good practices for Requirements Analysis?

• Draw a context diagram
• Create user interfaces and technical prototypes
• Analyse requirement feasibility
• Prioritize the requirements
• Model the requirements
• Create a data dictionary
• Allocate requirements to subsystems
• Apply quality function deployment

What are good practices for Requirements Specification?

• Adopt an SRS template
• Identify sources of requirements
• Uniquely label each requirement
• Record business rules
• Specify quality attributes

Remember that the goal is to develop requirements of sufficient quality and detail that managers can construct realistic project estimates and technical staff can proceed with design, construction, and testing.

What are good practices for Requirements Validation?

• Inspect requirements documents
• Test the requirements
• Define acceptance criteria

What are good practices for Requirements Management?

• Define a requirements change-control process
• Establish a Change Control Board (CCB)
• Perform requirements-change impact analysis
• Establish a baseline and control versions of requirements documents
• Maintain a history of requirements changes
• Track the status of each requirement
• Measure requirements volatility
• Use a requirements management tool
• Create a requirements traceability matrix

What are good practices for Project Management?

• Select an appropriate software development life cycle
• Base project plans on requirements
• Renegotiate project commitments when requirements change
• Document and manage requirements related risks
• Track the effort spent on requirements engineering
• Review lessons learnt regarding requirements on other projects (project retrospectives)

Should I adopt all the practices?

Please, No!

As I already said, you should think of these good practices as new items for your requirements tool-kit. Consider your business and processes and choose the practices that can provide you the most benefits.

You should never forget the 80-20 rule and that the most important thing is to have a continual improvement process.

The website associated with the book contains a lot of templates that can be used as a starting point. Unfortunately, you need to pay for them.

I would like to finish this post with a sentence with effect:

Gathering and validating requirements are among the greatest challenges is software development

Next post:

• Software Requirements - Part 3

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.

Next post:

• Software Requirements - Part 2

Top Coder Problem - Boxing

TopCoder is an amazing platform to challenge yourself.

I decided to start posting my solutions to problems with the following purposes:

• Stimulate myself to practice more
• Stimulate my friends to solve the problem
• Stimulate my friends to join TopCoder and challenge themselves
• Compare and contrast different solutions

Notes:

• TopCoder only accepts solution written in C# 2.0
• The problem statement is the exclusive and proprietary property of TopCoder. You need to login to see it.

TopCoder Problem:
Boxing

This problem was used for:
2004 TCO Online Round 3 - Division I, Level One


My solution:

Tests:

My solution is an usage example of the Greedy Algorithm Design Paradigm.

What is your solution?