3

A client asked us to automate his offline paper-based processes. He sent us a copy of the physical forms that he uses.

Our team met and discussed how the navigation should be, what major components would exist in the UI. That's it.

Problem is, we don't have actual "written" requirements. With a lack of an actual business/system analyst in our company, what are the steps that we should take to reach the point where we are ready to start developing the system?

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
SaryA
  • 33
  • 5
  • possible duplicate of [How to manage and estimate unstructured requirements received from customers](http://programmers.stackexchange.com/questions/171295/how-to-manage-and-estimate-unstructured-requirements-received-from-customers) and of [Dealing with bad/incomplete/unclear specifications?](http://programmers.stackexchange.com/questions/40676/dealing-with-bad-incomplete-unclear-specifications) – gnat Aug 22 '13 at 11:57

2 Answers2

2

Even if you don't have a business analyst, you'll need to have requirements in written form in order to:

  1. have a clear picture of what you are doing. No matter how many times you've discussed the application and how familiar you are with the details, you cannot guarantee to remember everything, and eventually you'll either miss a feature or deliver something else than the client needs.
  2. use the requirements in negotiations with the client. The client should see what they will eventually have in an early stage. If they want to change anything, the written requirements will help to see where, what and possibly why the change was made.
  3. protect yourselves. People tend to forget a lot. There is no chance that the client will remember every single detail of what you've agreed upon. If this happens, you'll have the document to prove otherwise.

It isn't necessary that you write the requirements as a business analyst would. Depending on the complexity of the system and on how obvious it is, even simple diagrams of high-level processes and UI can suffice.

If you still cannot have the requirements written, I suggest you build a simple prototype, discuss it with the client and continue working on that (though requirements and prototype don't exclude one another).

superM
  • 7,363
  • 4
  • 29
  • 38
  • 1
    Thank you for the advice. Yes, we should write a requirements document no matter how small/simple it is. – SaryA Aug 25 '13 at 11:54
1

Find out the business processes that he uses with the material.
Ask questions like:

  • Where does the data come from that he enters on the forms?
  • What happens to the forms after being filled out?
  • What does the typical data entered on them look like?
  • What fields are required?
  • What validations would be required?
  • Who uses the information once entered?
  • How long should the information be retained?
  • How should records be identified?
  • What would users want to search on to find records?
  • What additional functionality is already expected from automating the process?
  • What is the timeframe or time limits?
  • What external changes are expected/possible in the next year that would affect a solution?
Michael Durrant
  • 13,101
  • 5
  • 34
  • 60
  • 1
    Then write an FRD document which describes your understanding of the business processes and how your system will address them. The client must sign this off in order to show that they have read and agreed to the proposed work – Charleh Aug 22 '13 at 11:27