Tech Off Thread

8 posts

LOB Requirments Document

Back to Forum: Tech Off
  • RamblingGeek​UK

    I have been asked to write a document to describe the requirements for a LOB system.  I'm a novice programmer, make my living installing and maintain networks for customers.    A client has asked if I could assist in this for them and thus I'm looking for examples of what developers require. 

    Any assistance would be appreciated.

  • spivonious

    @Kryptos: Clearly worded, unambiguous functional requirements and nothing more. Let the developer(s) figure out architecture, design, what the UI should look like, etc.

    The actual document format doesn't really matter. Something as simple as a bulleted list would work, all the way to something full of workflows, charts, and images.

  • JohnAskew

    "As a [role] I want to [action] so that I get [result]."

    This is a simple, unambiguous sentence structure for requirements that is used in Agile development methodologies like SCRUM.

    I recommend it because, with this structure, a savvy coder can get their audience/users to draft the requirements themselves -- and there is no better way to stay on the same page and get it right than this way.

    So once more:

    "As a [role] I want to [action] so that I get [result]."

  • RamblingGeek​UK

    Thanks guys.   This is all good food for thought.

  • Dr Herbie

    Another format that's useful for testing (both integration testing and user acceptance tests) is a numbered list of statements where each statement is a single fact about what the software must do.

    E.g.

    1. The system must require the user to log in with a unique username and a password.

    2. The system must supply an option to allow the user to change their password once they are logged in.

    3. When changing a password, the user must supply their existing password as well as their new password.

    ...

     

    Break it up into sections based on functional areas so it isn't too overwhelming.

    In this format it's easy to do through the list and check off each item when testing.  It can also form the basis of the user's sign-off when the system is complete.

    Herbie

  • vesuvius

    @Dr Herbie: Imagine you have to write on bitlocker http://technet.microsoft.com/en-us/library/cc732774.aspx

     

     

  • JohnAskew

    @Dr Herbie:

    "As a [user] I want to [be able to change my password, once logged in, using my existing password for verification,] so that I can [better protect my user security myself]."

    I was looking at your 3 item list and wanted to use it to show just how much more clear the requirement becomes when using the sentence structure from Agile - SCRUM.

    Personally, I tend to read one line at a time. In fact, since these are all related to the same feature, my understanding of one line may affect my understanding of another of the lines. That came out poorly, what I mean to say is that all those lines can be put into one clear statement instead which will only serve to clarify and streamline comprehension of the requirements for all involved.

    Why John doesn't approve of Herbie's list as requirements document: Angel

    1. The first part, [role], specifies who the feature is targeting; admin, regular users, etc... A developer will either have to make an assumption here or ask for more information if this is not included. So you can see that the sentence structure itself already protects against ambiguity and confusion.
    2. The second part, [action], is rather verbose, but that isn't a bad thing. Features will often require more than one 'sentence' or requirement. This feature, for example, leaves admin's password requirements to be defined, as well as the "I forgot my password" user scenario... More sentences. 
    3. Notice the last part, [result], shows the 'why' for a requirement. Omitting this "reason for a requirement" allows features to be implemented without considering their value to the system. In addition, requirements can be ordered by importance when their value is assessed.

    Herbie's list should do fine as an integration test list, but I would have it be derived from the "User Stories" which are compilations of multiple sentences with the structure described above.

  • Ion Todirel

    And don't forget diagrams, and UML. Oh, and you need a PM Smiley

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.