[Last Call] Learn how to a build a cloud-first strategyRegister Now


During software requirement gathering phase

Posted on 2011-05-07
Medium Priority
Last Modified: 2012-05-11
Dear EE members,

I am talking about User Requirement Gathering phase in software development life cycle.

As usual, the end-user will request a lot of requirements to convert the current manual system to a computerised

As a fresh software developer, how to know what type of user requirement can be accepted and what type of user requirement is impossible to implement?


Question by:yjchong514
  • 2
  • 2
  • 2
  • +2
LVL 27

Assisted Solution

BigRat earned 400 total points
ID: 35722119
It is very difficult for people to imagine something which they have never seen. Consequently they will request things for a computerised system which they found lacking in a manual system.

It is not a question of what is impossible to implement, for given enough time one can implement almost anything. It is more a question of whether the new system is an improvement over the old - even if the manual system is the new system!

In the old days one had people called Systems Analyists whose job is was to capture such requirements in a structed manner. They were frankly a waste of time.

The only way to know what the new system should do is to learn the jobs of the people for whom you are going to write the new system. Once you have written the system and put it into place YOU must use it. Putting in an odd button or link here and there is trivial after the system is in operation.
LVL 101

Assisted Solution

mlmcc earned 400 total points
ID: 35722253
SIt down with the user and find out what it is they do now.

For instance an order taking system
First is to figure out if they are trying to automate taking orders over the phone or if the users currently send an email with the order and want the users to enter the order into a system that puts it into the database.

What is done now?

What are the issues? - speed, accuracy, etc.

Perhaps you could sit down with a user and watch how they do it now.  See where the bottlenecks are.

LVL 32

Assisted Solution

phoffric earned 600 total points
ID: 35722652
>> As a fresh software developer, how to know what type of user requirement can be accepted and what type of user requirement is impossible to implement?

At our company requirements capture is handled by experienced Systems Engineers who have an excellent grasp of both Software, Hardware, and Systems Architecture. Knowing what equipment you need to meet requirements is critical to developing a system.

Here's how we handled requirements (very short version).
For every requirement that must be implemented, you make a statement with the word "shall". This "shall" statement shall not have more than one requirement. For every "shall" statement, write a corresponding test in a Systems Test Document that will fully verify the correctness of the "shall" statement. If unable to figure out how to test this statement, then remove the requirement.

For requirements that are heavily operator interface based, write an operations procedure document (along with a rapid prototype program) that illustrates the user interface using the GUI.

Whether a customer can understand what they want or not will become a moot point if you write down the requirements and GUI and get the customer's signatures for you to continue work. The signatures forms a contract, and if you word your requirements very clearly and tightly, then you and they will know what will be built.

Any changes to these documents (even during the design phase) requires an Engineering Change Request that requires customer signatures (and usually additional costs). Documentation is not cheap.

In complex projects, the documents are broken down in phases - first a top-level view followed by a fine detailed view.

Regarding Operator Interface.. If the customer can complain about the GUI not having the right buttons in the right place, then make sure that these minutia details are included in the documents so that any future complaints are accompanied by a check for the additional changes to the requirements. If it isn't written down, then the customer can complain and often, you will have to eat the costs.
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

LVL 21

Assisted Solution

developmentguru earned 600 total points
ID: 35726375
 One important thing to know is that you need to be able to discern what the user wants, as opposed to what they ask for.  I had to gather requirements for a new report.  Sound simple?  The user had been running the same two reports on a mainframe system for 30 years.  He said, "I have to select report 1 or report 2.  I understand that is what is available.  I was thinking that if I chose report 1 and entered a start date that was kind of, sort of, close to the end of the month... then it would run the new report!"  He could not conceive that we could simply add option 3.  Never mind the fact that computers don't do "kind of, sort of, close to" anything LOL.  What he wanted was a way to choose a new report.

  Another user said, "I know that there is software for automatically translating from one language to another.  What I want you to do is make it so I can enter an order in Spanish when I am in the field, have it go into the office and be translated into English (so the in house people can work with it), then translate it back to Spanish for me when it is sent back out."  I had to try to explain that while software does exist for one way translation, that it is not nearly good enough for round trip translation.  Software to handle his requirements would have to have some amazing AI, understand the companies business, and know the users intentions at the time his order was entered (and/or when it is modified in house) in order to make a good round trip translation.  I will not say that such a project would be impossible, but I can almost guarantee that no one would be pleased with the time or monetary investment required.

  As long as you learn to understand your client and his job then you will be able to see what it is he/she wants to do.  The only other decision is if you have the tools to make it happen in a reasonable period of time.

Author Comment

ID: 35727677
Can you give an example for:
For every "shall" statement, write a corresponding test in a Systems Test Document that will fully verify the correctness of the "shall" statement. If unable to figure out how to test this statement, then remove the requirement.
LVL 21

Accepted Solution

developmentguru earned 600 total points
ID: 35731873
 The level of detail you are trying to put into your process sounds like severe overkill.  I try to make sure that each requirement is able to be checked off when it's criteria is met.  In order to do this you need to be very precise with the requirements.  You cannot say, "the system will be able to do requisitions" and have that as a requirement.  You need to know the fields they want in the header of the requisition, the fields they want in the line items, what type of printed output it should produce, the format of the printed output, etc.  Only when you have it specified in great detail will you have something that can be checked off the list to show that it has been done.

  I worked at a company that did custom development work for larger companies.  The management signed an agreement that gave the customer complete authority to say when the project was done and set the price.  The company continued to add sections to the program, that were never initially specified, as the months and years rolled by.  They started by wanting a system that would let them enter requisitions.  Then they said it could not possible be called complete without handling purchase orders.  Then they said that it had to have a receiving section.  None of these were mentioned in the initial talks.  When the company went belly up (inevitable I know), the same customer wanted me to do work for them.  I spent two weeks of my own time, without being paid, in order to set up a very specific agreement of the requirements.  They also wanted a set price on the project again.  I put in a final clause stating that if they wanted to change the requirements after the project had begun that it would revert to a dollar per hour rate.  It wasn't 15 minutes after the agreements had been signed that they wanted to add 3 new reports without changing the price.

  Requirements gathering is about 2 things.  1) making sure the customer gets what they want and 2) making sure you get paid for the agreed work.

  There will be no comprehensive set of automated tests that can be done in order to keep your requirements realistic.  What is realistic is based mostly on your capabilities (not something you could put into a codified test) but it is also based on hardware and software limitations (with many other possibilities such as geographic location and internet access - as well as access speed).

  When it comes right down to it, you need to know what you can do within the circumstances the client allows.  I hope this helps you to gear up for handling your own requirements gathering process.
LVL 32

Assisted Solution

phoffric earned 600 total points
ID: 35733348
My cases of untestable shalls were very complicated. But here's an easy example. If the customer told you to make the GUI operations easy to understand, you might be tempted to write:
The GUI shall be designed to make the operator procedures very easy to understand.

How would you test this shall statement to yield a PASS/FAIL status?

In your team's mind, you could have a test to prove it (for your team) because your team has a notion of "easy" which may not correspond to the customer's notion. What is happening in this case, is that requirements writer is making assumptions about the customer's skill level.

>> "the system will be able to do requisitions"
If you turned this into a shall statement, then here again, you are making assumptions that you understand what the customer wants. (Maybe you were even told what they want.) But once you put things down in writing, then if it remains this high-level, the customer may say you have to do it over. It is quite frequent that you will get different conflicting requirements from different branches of "the customer". End users may have one set of requirements; and the ones who pay the bills may have another set. By writing down less high-level requirements and adding more detail, and getting signatures, you now have a workable contract.

Unfortunately, the language itself is full of ambiguities, and it often takes lawyer-like precision to make the contract completely clear. So, you may wish to increase the proposed cost a little to anticipate disagreements where you eat the costs.

Author Closing Comment

ID: 35736463
Dear EE members,
ALL of you have given me the BEST opinion.
I appreciated your kindness.
Thank you!



Featured Post

Important Lessons on Recovering from Petya

In their most recent webinar, Skyport Systems explores ways to isolate and protect critical databases to keep the core of your company safe from harm.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

In this post we will learn how to make Android Gesture Tutorial and give different functionality whenever a user Touch or Scroll android screen.
Make the most of your online learning experience.
Viewers will learn how to properly install Eclipse with the necessary JDK, and will take a look at an introductory Java program. Download Eclipse installation zip file: Extract files from zip file: Download and install JDK 8: Open Eclipse and …
Integration Management Part 2

825 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question