Software Engineering: How do you start?

There are interesting challenges in applying the art and science of Engineering Disciplines to Software Analysis and Design.

If we accept the notion that we need as complete a collection of Requirements as possible either for a full blown application solution (change or new) or a SPRINT to add functionality to either an existing application or to get a new one started, then we also need to decide which models we are going to use to collect these requirements from the Business Users and Sponsors and record them so that the Development and Testing efforts can be coordinated.

The model choices we have are several:

• Object Models
• Data Models
• Process Models
• Swim Lane Diagrams
• Use Cases
• State Transition Diagrams
• Event Diagrams
• Data Mapping Diagrams
• Nassi / Schneiderman Diagrams (don’t remember these?)
• or simple Flowcharts (a real throwback to a long time ago!)

Which ONE is a good start?  Which combination will the Business Users and the Development and Testing teams understand with sufficient similarity that we can believe we are all talking about the same solution and not something that is not clearly communicated?

One suggestion I would propose is that the “Engineer’s” in the project team do NOT pre-select a model to start with.  Instead, prepare a list of fairly open ended questions for the Business Users and Sponsors and LISTEN to what they have to say about how THEY envision their solution.

You may find that they are very comfortable talking about the information that is available and supportive of their hoped-for solution AND they might also talk about the business events that occur when the data is first available and other events that will change the nature or state of that data as it is used in performing the business.  OR, your users may be more comfortable describing their solution in terms of the Objects or Topics of Interest and the behaviors that they demonstrate as the solution delivers its capabilities.

Once you get the sense of how your users like to describe their vision of the solution, you can pick two or three of the appropriate models to show that you “Get” what they have been saying AND you can also introduce them to the models that seem to represent their vision as close as possible to the ‘syntax’ that they are comfortable with.

The translation of their narratives to you about “Requirements” and the feedback from these diagrams should (underline and bold “should”) facilitate the communication between the Technical and Business contributors assigned to your project.