Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

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?

share|improve this question
add comment

marked as duplicate by gnat, Corbin March, Dynamic, Yusubov, MichaelT Aug 22 '13 at 14:55

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

2 Answers

up vote 2 down vote accepted

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).

share|improve this answer
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
add comment

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?
share|improve this answer
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
    
Great checkpoints. Thanks. –  SaryA Aug 25 '13 at 11:54
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.