Software Project Management - Gathering of Hidden Requirements

Software Project Management - Gathering of Hidden Requirements

gathering requirements

When you start a software development project you need to visit your customer many, many times, and get requirements that must be met in order to fulfil a contract. A contract where your product represents some value to your customer. This value might be becoming more competitive, being able to response to their customers’ needs faster, being better organized and so on. There are many ways to gather these requirements that I'm not going to talk about. What I'm going to talk about are the problems with getting requirements done on time.

user stories

There is a number of requirements that I calll 'soft' requirements, which are often called 'user stories'. They represent primary scenarios that your software is going to cover. They are things like 'create customer record', 'edit customer record', 'issue invoice', 'generate report'  and so on. These are parts of the code that you are definitely going to implement as they represent a value to your customer and the reason you've been called to work for him. And typically they are not that hard to gather.

technical requirements

The other type is technical requirements that must be met in order to run you software at customer's machine. Most obvious requirements include: framework (e.g. Microsoft .Net Framework 3.5), operating system (e.g. Windows Server 2008 64-bit), database type (e.g. Microsoft SQL 2014), file server capacity (e.g. 20GB for archive), database capacity (e.g. 5 GB). These requirements will usually be set at the beginning of the project and in most case create no problems to both sides.

requirements always change

Change is one of the most important aspects of software development. It is the only thing that is to be expected. Change is the key word. The one and only thing that you may be sure of. There is no single project in the world and there will not be a project in the world that is identical at the beginning and at the end. Requirements that you gather starting a project will change inevitably as you progress towards its. Sometimes customer will change requirements at the beginning, sometimes in the middle, and unfortunately sometimes at the very end. The last case is the most dangerous if the changes are fundamental. Bad change management kills budgets, causes stress, makes people leave your company and, if worst comes to worst, may even lead to bankruptcy.

customer adds requirements

When customer adds or changes requirements that are fundamental and/or time consuming to implement, you run into problems. Sometimes you have to change the scope of the project: agree with the customer that some requirements must be excluded from the current version to make room for new/changed requirements, sometimes you may be able to negotiate budget extension and/or changing the date of delivery. But sometimes customer is not willing to make your life easier and tries to force you to finance these changes yourself but still meet the deadlines. Below you will find some of these hidden requirements that may ruin your project

find project neighbours

Some of the requirements that customer forgets to give  you are those added by people that were not involved in the project at the beginning. It may be someone from legal, security, marketing or any other of your customer’s departments. You role is to insist on the customer that he finds project neighbours since the earliest stages of the project and warn that if he fails to do so, he will be charged for additional changes. Being proactive here is crucial.

IT environment special restrictions

Very often when you try to run your software at the customer's server it is clear that it's not possible to use it because there are restrictions you did not know about. You did not ask or customer forgot to tell you. For example you find that you can't connect to one of your application’s modules because HTTPS protocol is required instead of your HTTP implementation. Or you find out that what you work on is a multi-server environment that switches automatically between servers for the purposes of load balancing or as a part of failover procedures. Or there are firewall restrictions. Or slow WAN connection that timeouts very often. Or there are millions of records in an important table so you can't just throw typical sql query at it. Or an important module that you have to use is Java based while you are a .Net developer. Or your EXE is 64-bit while a 3rd party DLL that you are obliged to use is 32-bit. There may be many similar or totally different situations. Your role is to keep asking your customer about such restrictions and possible problems, also by contacting all those hidden project neighbours - people from other departments, or other rooms. (Yes, sometimes it saves you bucks and trouble just by visiting next door to your customer's project owner room). Gather technical documents that are available about IT environment elements, ask for them

security restrictions

In real life your customer often is a business administrator and has administrator privileges on the computer the software is installed on or they have such privileges but only at time of installation. Then your software can run using typical user account. Developers often forget about it and test everything at their development environment using administrator accounts. You need to install a fresh operating system and try to simulate the customer's environment as deep as you can. Install your software and add put all the special privileges you had to grant it in order to run properly (folder privileges, database privileges, network privileges).Remember to put each end every privilege you had to grant in your documentation. At the same time you need to remember that some privileges can't be granted because of security restrictions that can't be avoided. Assume that you can get neither administrator privileges nor full control on files and databases.

performance tests

This is another set of requirements that almost nobody speaks about at the beginning of a project. Things that become obvious during... UAT. Your customer expects that software generates reports in 15 minutes like he did with his old software, while it takes him 50 minutes to do the same thing with your software. Or that typical use of client UI involves running procedures that take many minutes to execute and make UI unresponsive, without progress bar, without any way to stopping the task. Ask simple questions that make it clear how fast the software has to work. In seconds, in minutes whatever, but measurable. Do not use requirements description like 'application must be fast'. It does not say anything. Assume that any table or folder that may grow will grow to thousands and millions of records or files and test your software with such numbers. Optimization can be a very complicated  process and requires unusual skills. Iit may require additional budget and time that has to be allocated.

risk list

Even if you try very hard to gather all obvious and all hidden requirements sometimes you realize too late that you did not get some important information on time, and your software fails to run, or it is not possible to promote it to production because of some unexpected business requirement. My advice is that you clearly express to your customer that there are such risks. You have to do it at the very beginning.  Not in the middle, not at the end. Your customer expects that you are an expert and you inform him about possible risks up front. Especially when the IT environment is new to your customer (new server room, new cloud etc), or this is a completely new business process, or you are obliged to you 3rd party modules, risks are inevitable. Don't hide, describe these risks at the meeting with a customer, put them on paper so nobody forgets it, and nobody blames you in case you were right. Problems will happen but your role is to minimize their impact by anticipating places where they can happen. The customer must be prepared for possible problems too. Thanks to clear information about risks your customer may decide to put more resources in helping to avoid problems.

Thanks for reading :)

Dominik Steinhauf
CEO, .Net developer, software architect
www.indesys.pl

If you need help with your software project, or need customized software for your company, contact me at: dominik.steinhauf@indesys.pl

 

Brigitte Schmidli

Product Owner / Product Manager NEST Steuern @ KMS AG

8y

Thanks for sharing...

Valentina (Cupać) Jemuović

Technical Coach | Want zero bugs and fast software delivery? DM me to find out how I can help your teams

8y

Excellent overview of risk factors.

To view or add a comment, sign in

Insights from the community

Explore topics