2

We have a project here in my company of developing a new CRM. It's, basically, a big CRUD, with sub-CRUDS, with various details, such as, some users can do that, others don't. We will develop the system in PHP with Symfony. Developing is easy, but we're having some difficulties in the analysis part of the job.

We have to present the project specification, as well the tecnical specification of the project. We have to draw and explain how to system will work. And we're not sure on how to do this. We always just... did the system. Not planning with graphics or text, or explaining what we were doing.

We already asked everyone and got suggestions, as well requirements. Apparently, we have to take that and explain the system.

Any tips, guys? :)

  • So what you're asked to do is basically... documentation? –  May 02 '11 at 13:41
  • 1
    If you don't create technical requirements and designs how do you know when you are finished and the program does what it is suppose to? Without either testing to make sure your product meets those requirements are hard. – Ramhound May 03 '11 at 15:07
  • If you are having trouble with the analysis part of the jonb I can almost guarantee your sytem will not perform as expected. Particuarly if you are thinking of this as a CRUD system. CRM's value lies in reporting not CRUD. If you are designing for just CRUD, you are in deep trouble. – HLGEM Jun 02 '11 at 14:36

3 Answers3

3

Although quite heavyweight, whenever I have had to document a software design I usually went for the MIL-STD-498. I'm not saying you should produce (at least one of) each of the 22 document types it consists of, but rather to just choose one or two that make sense and then use the layout as a general guideline.

The one you might need is the Software Design Description (SSD). The nice thing about this approach is that you more or less dodge a discussion about whether your document will contain at least the required parts (it's one of the good things about using a standard that people tend to assume it's good for what it's for).

The documents tend to cross-reference heavily, but instead of writing all the other documents you can just define these things in-place in the document.

Deckard
  • 3,417
  • 1
  • 22
  • 32
0

I am assuming what the issue is that you are facing is how to model what the system will do in a way that your client can see and understand. If that is the case, look for a tool like Sketchflow. Sketchflow specifically is attached to Expression Blend and is used for WPF and Silverlight sites. However, it could be used for other development as well and the concept is the same if you were to look for other software to do this. Basically, it allows you to model out what a site will do without putting major development hours in. It then allows the customer to see and "feel" the site and they can then better communicate what they like and don't like before you invest time in creating something.

IAmTimCorey
  • 217
  • 1
  • 4
  • We have to document the system specification. –  May 02 '11 at 14:25
  • Can you elaborate a bit? If you are talking about documentation of what the system will do in graphics and text, I would still use Sketchflow and then screenshot it and put it into Word with a written explanation. If you are talking more about the system performance and scalability, that would be a different matter. –  May 02 '11 at 14:53
  • Balsamiq could be even better since its not as tied to WPF/Silverlight. – Morgan Herlocker May 05 '11 at 14:46
0

Perhaps you need to hire the correct people to do the job. You need at a minimum a business analyst and a database specialist. Requirements for something this complex is a job you do first and then base all testing and code reviews on as well as actually following it for the development. You don't do this afterwards to satisfy some customer requirement.The application that enters data is the least important part of a CRM system.

HLGEM
  • 28,709
  • 4
  • 67
  • 116