How To Define Scope on Software Development Projects: Functional and Non-Functional Requirements

Written by Jamal Moustafaev on May 7, 2012. Posted in Articles.

The Story Of A2LL

A2LL – the German social services and unemployment software system was developed over the course of several years by T-Systems – a software department of state telecommunications company – along with ProSoz, a smaller company of about thirty developers located in the town of Herten.

The final product was delivered in the last quarter of 2004 and went live on January 1, 2005. The system consisted of the web browser front end, while the back end was based on 16 servers with 4 processors each.
Upon the deployment of the system at several large German cities including Cologne, Hamburg, Frankfurt and Berlin, the users at the welfare offices started reporting serious problems with the software. Some of the problems encountered are listed in Exhibit 1.

Exhibit 1

System Bug Description	Type of Requirement
If data entered into the form was incomplete (e.g. someone missed one of the many questions) the system automatically deleted the record after about three or four weeks	Functional
Account numbers that were less than ten digits in length were filled with zeros at the end of the string rather than at the beginning (e.g. 3225223 became 3225223000 instead of 0003225223).	Functional
System was not capable of producing an “Analysis of Variance” report	Functional
System was not capable of producing a “Persons Who Received Too Much Money” report	Functional
System did not include the functionality to deal with the deductions for income from small jobs	Functional
System could not cope with one-time payments (e.g. schoolchildren purchasing books)	Functional
System was not registering people properly with their insurance companies	Functional
System could not properly calculate insurance rates resulting in 25 million euros per month overpayment to the insurance companies	Functional
Extremely slow response time of the software	Non-functional
Extremely slow data entry times	Non-functional
Document printing was incompatible with many local stations	Non-functional

As a result of the above-mentioned deficiencies the expert committee appointed by the German government has concluded that the system was inadequate and started considering a new software system, just nine months after A2LL went live.

What are the lessons that can be learned from this project? It looks like the failure of this endeavor is rooted in project team’s inability to extract and document the proper system requirements (both functional and non-functional). After all it is less likely – at least in the author’s humble opinion – that the requirements were captured and included in the Requirements Specifications documentation properly but neglected by the developers.

The inability to properly define the detailed-level scope of IT and software development projects has unfortunately been the root cause of many failures in the hi-tech industry. According to the Standish Group five out of the eight top reasons why projects fail are related to requirements:

Incomplete requirements
Lack of user involvement
Unrealistic customer expectations
Changing requirements and specifications
Customers no longer need the features provided

Furthermore, between 50-60% of errors in software development originate in the requirements
stage. Rework needed to remove requirements errors can account for as much as 50% of software development projects. And finally, requirements errors are the root cause of 70-85% of rework cost.

Therefore since proper scope definition becomes one of the key factors of project success, this article is dedicated to the extraction and documentation of the functional and non-functional requirements of the system.

Requirements Specifications Template

Exhibit 2

There is a multitude of software specification templates available in various textbooks, Internet sites and other sources. They include user classes, operating environments, constraints, assumptions, dependencies, various interfaces, etc.

The purpose of this article however, is to concentrate on the two major sections of these documents that usually account for 80-90% of the overall volume – functional and non-functional requirements (see Exhibit 2).

Functional Requirements

Agility Guide For Functional Requirements

Many of the companies I consult for have been asking me “Well we have switched to the Agile methodology now and we are not sure how to treat our requirements processes now. For example, Do we still have to document them? And what about requirements management?”

My answer to such questions is that regardless of the project management methodology used, traditional waterfall or one of the Agile varieties, sound requirements engineering practice must exist in the project team. Here is a dumbed-down example that I once used during a conversation with a young and overly enthusiastic business analyst:

BA: Do all the rules of traditional waterfall requirements engineering apply on Agile projects?

Me: Let me ask you several questions, if you don’t mind. Pretend you are working on a very conservative waterfall project and have recorded the following statement in the requirements specifications document: “The home page shall load quickly”. What do you think will happen?

BA: The developers will probably insist that I specify the “quick” part; they would probably want to know how fast the page should load.

Me: Perfect! Now imagine you are working on a very Agile project and you write this requirement on the whiteboard or even simply mention it to one of the programmers in the same format. What will his reaction be? Do you think he will find it acceptable?

BA: Hmm … I don’t think so. He will still need to know how fast the page should load.

Me: Aha, so it is the formality of the requirements engineering and not the quality of extensiveness of it that is defined by the agility of the project management methodology!

Before we move one to describing the formality of the requirements approaches let us define three broad project categories first (see Exhibit 3).

Exhibit 3

Project Type	Project Attributes
Agile projects	Highest degree of agility Smaller projects Close stakeholder participation Smaller number of stakeholders
Traditional projects	Very large in size and number of stakeholders Very complex Contractual obligations
“Something-in-between” projects	Try to be as agile as possible Have constraints imposed on them by project and/or organization Probably larger than Agile projects but smaller than traditional ones Probably have more stakeholders than Agile projects but less than traditional ones

So, what are the guidelines for recording functional requirements on various types of projects (see Exhibit 4)?

Exhibit 4

Project Type	Formality Level
Agile projects	Typically avoid writing formal requirements However, rushing to a solution before understanding the requirement will lead to wasted effort
Traditional projects	Have a need to formally write their requirements Could use scenarios and/or use cases to communicate requirements
“Something-in-between” projects	Try to be as agile as possible Have constraints imposed on them by project and/or organization Probably larger than Agile projects but smaller than traditional ones Probably have more stakeholders than Agile projects but less than traditional ones

What Are The Requirements Writing Guidelines?

There are several simple rules that have to be followed when recording functional requirements.

Firstly, let’s examine the concise writing rule. This rule consists of several sub-categories. Statements should be short and to the point. They should focus on what the system must do rather than on how it should do it. Also, one of the most difficult aspects to achieve – the statements should not leave any room for interpretation. This task becomes easier to achieve if the writer attempts to record one requirement per statement or paragraph with one verb.

Another good tradition to follow is to consistently use the word “shall” rather than mix “must”, “will”, “might” and “may” to indicate priority and/or create a semantic confusion.

Here is an example of a bad requirement for the readers to analyze and attempt to re-write properly:

Product SKUs entered by the customer will be validated against the SKU master list if possible and the results will be presented in the tabular format to the user

Some of the issues a good requirements expert will notice about this statement are:

Usage of “will” instead of “shall”
“will be validated” – validated by whom or what?
“if possible” – and what happens if it is “impossible”?
“results” – what kind of “results”?
“tabular format” – imposing solution
No unique identifiers
Usage of word “customer” instead of “user”

A possible improved version of the same requirement may look something like this:

FR 1.3

The ABC system shall validate Product SKUs entered by the user against the SKU master list

If the SKU entered can be located in the SKU master list, the ABC system shall communicate to the user that the product was found and prompt the user to add the product to the shopping basket

If the SKU entered cannot be located in the SKU master list, the ABC system shall communicate to the customer that the product was not found

Exhibits 5-7 list additional attributes of quality requirements.

Exhibit 5

Exhibit 6

Exhibit 7

Requirements vs. Design Discussion

One of the key issues that I have witnessed on numerous IT and software development projects is over-eagerness of the project stakeholders – both technical team members and customers – to delve into the discussion of the granular design aspects of the final product well before all the functional and non-functional requirements have been defined.

Sometimes the remarks of more experienced team members that the location and the color of the “Submit” button should be postponed until later were very frequently met with the following comments;

“Well, we know this now; why postpone the discussion until later?”

There are two main reasons for separating functionality and design discussions. The first one is that defining the functionality of any software product is a complicated and cumbersome process that has not been fully grasped by many IT professionals. Adding the design-related discussions into the mix complicates things even more and distracts both team members and customers from more important aspects.

Secondly, one should always remember that technical team members (e.g. developers, architects, etc.) typically have a much better understanding of various design options available to the team. Thus it is only logical to expect that developers, architects and UI designers will be able to come up with more efficient and innovative solutions. Furthermore in many cases these solutions could be the ones that the customer did not even know were possible.

Before we explore this topic further, let us look at the respective definitions of the requirement and technical design.

Requirements describe what the customer wants – they communicate business capabilities required to solve business problems or achieve business objectives.

Technical design describes how the requirements will be satisfied and which system components will deliver the new capability.

How can one distinguish between a functional requirement and a design-level solution? One of the easiest ways to weed out design elements in the specification document is to look for phrases like:

“The system (or customer) shall do X by …”

See Exhibit 8 for several examples of design sneaking into requirements.

Exhibit 8

The system (or customer) shall do X by …	Question
… choosing an option from a dropdown menu	Why does it have to be a dropdown menu necessarily?
… pushing a “Submit” button	Can it be “Proceed to Checkout” button instead?
… clicking in the checkbox	Why not radio button?

Parking Lots

What frequently happens during the requirements discussion meetings is that great, cool and incredibly innovative design solutions unexpectedly “pop-up” all over conference rooms. The obvious question at that point of time, “If we are not venturing into design issues right now, what do we do with these cool ideas?”

The solution is to create a “parking lot” in order to capture these “too early to discuss” items in order to revisit them at a proper time of the project. Parking lot can take several forms depending on the complexity and the formality of the project. For example, more Agile project teams may decide to use whiteboards or flipcharts to capture design ideas.

On the other hand it is recommended that more sophisticated projects capture this info in the special section of the System Requirements Specifications document (SRS).

Don’t forget to leave your comments below.

Bibliography

“Software Requirements, Second Edition (Pro-Best Practices)” by Karl E. Wiegers
“Effective Requirements Practices” (Addison-Wesley Information Technology Series) by Ralph R. Young
“Exploring Requirements: Quality Before Design” by Donald C. Gause and Gerald M. Weinberg
“Requirements by Collaboration: Workshops for Defining Needs” by Ellen Gottesdiener (Kindle Edition – Feb 17, 2009)
Mastering the Requirements Process (2nd Edition) (Hardcover) by Suzanne Robertson and James C. Robertson
“Project Management Body of Knowledge (PMBOK)” by Project Management Institute (PMI)
http://en.wikipedia.org/wiki/A2LL