During software requirement gathering phase

Posted on 2011-05-07
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
    LVL 27

    Assisted Solution

    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 100

    Assisted Solution

    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 31

    Assisted Solution

    >> 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.
    LVL 21

    Assisted Solution

     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.
    LVL 6

    Author Comment

    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

     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 31

    Assisted Solution

    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.
    LVL 6

    Author Closing Comment

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



    Featured Post

    Highfive Gives IT Their Time Back

    Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

    Join & Write a Comment

    Suggested Solutions

    Communication between departments might not happen in two different languages, but they do exist in two different worlds. With different targets and performance goals the same phrase often means something completely different to each party. Learn ho…
    Whether you've completed a degree in computer sciences or you're a self-taught programmer, writing your first lines of code in the real world is always a challenge. Here are some of the most common pitfalls for new programmers.
    An introduction to basic programming syntax in Java by creating a simple program. Viewers can follow the tutorial as they create their first class in Java. Definitions and explanations about each element are given to help prepare viewers for future …
    In this seventh video of the Xpdf series, we discuss and demonstrate the PDFfonts utility, which lists all the fonts used in a PDF file. It does this via a command line interface, making it suitable for use in programs, scripts, batch files — any pl…

    745 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

    Need Help in Real-Time?

    Connect with top rated Experts

    16 Experts available now in Live!

    Get 1:1 Help Now