Lessons Learned: Writing Software Requirements

Kishore C.S.

October 1999

Software requirements document is the medium used to communicate user requirements to technical people responsible for developing the software. It is important that documentation talks from User Perspective than System perspective. Even the language used makes a difference in the way system will be designed and developed. Requirement document should emphasize on User behavior and activities.

In his book ‘About Face’ Allan Cooper discusses the goals of a software users (who are employees of organization like you and me). Employees’ have goals to achieve in their organizations. Goals are:

• to get more work done
• not to feel stupid using the system
• enjoy working with the system.

 If the above goals of users are kept in mind one can understand that users will hate to use a system that is not intuitive. System should conform to user’s behavior. Systems that understand users behavior and help them in achieving their goals will enlighten them. Otherwise companies will continue to develop and deploy software systems that will never be used by intended users.

Focus on User will ensure the software will meet user expectations. ‘Microsoft Secrets’ book discusses the questions to be answered at requirements stage. This has helped in Microsoft designing software that users like to use. 

Unified Modeling Language (UML) Conventions of Requirement Documentation suggests identification of Users for software very clearly and writing ‘use cases’ from the user’s perspective. Identifying the actual employees of the organization as a user will shape requirements better. Instead of identifying a generic user be specific at the target segment. The Users can be: Shop Floor Personnel, Production Supervisors, General Managers, Product Managers or CEO for Enterprise for Applications that are designed for Enterprise Wide use.

Know your user. Identify yourself with the user. Each user has different activities to be performed and different goals in mind. Designing a single interface to meet multiple objectives does not make sense. The more specific the user identification the better will be the requirement documentation.

At requirements stage identifying the specific users of the system and using the same user identification throughout the documentation will result in better quality of product. This perspective given to product from requirement stage can be carried on till testing and deployment stage and the usability/acceptability of system will improve dramatically.

How requirements can be re-worded is illustrated in the following examples:

Example 1: Login Validation

            A. System will prompt for User Identification and password.

B. User will start accessing the system by identifying himself.

Stating the requirements in format (A) will assume that the user will be given an identification and password and design team may even assume that he will use a keyboard to enter the same. This language is from System point of view.

Format (B) does not conclude on the interface. This just states the need. This may mean he can use so many options available of identifying himself. This can be met by

1. entering user id, password through keyboard
2. Using a Swipe Card following by a password
3. The system may use advanced systems like validating finger prints, face or voice recognition.

Example 2: Sample requirement for time tracking system.

I was involved in design and development time tracking system. The tendency was to think from what information software needs to capture than what the user would like to give as input. This kind of requirement document will necessitate rework in the system before it can be used. Now I feel if the wording of the requirement has been different the software would have been more successful.

1. User will enter number of hours worked per day for the tasks that are assigned to him. User will be able to view his tasks and view his team members task if he has a team.
2. The system will be used by Supervisors, Team members for assignment of tasks and monitoring tasks. The Supervisor is interested in transferring his project plan to individual tasks into the system. Team Members will report time spent against each task.

Format (A) is very generic whereas Format (B) addresses specific requirements of individual Users. Requirements written in this format can lead to better design. Users will be happy to use the software designed in this manner.

Success of software depends on its relevance to the user. People will not use systems if they are forced to. Only if they feel it is going to improve their performance they will adopt systems easily. Designing systems that will help users achieve their goals will have higher success rate. From Requirements stage to Deployment and Support always keep the user in mind.

At every stage question yourself: "Will I use the system if I am user of the system I am developing?". For example, while writing requirements for Inventory Transactions one should imagine himself as the person who is a factory taking care of stores. What help would the person in Stores need to be able to reach his goals?

When this kind of questions are answered by everyone involved in the software development then only the system will be designed/developed well and will have easier acceptance.

Don’t develop systems for the sake of developing. They will not add any value. Seek to add value to others and you will succeed.

References:

[1]. About Face – Allan Cooper

[2]. Microsoft Secrets – Michael A. Cusumano, Richard W. Selby

Back