Techniques for setting requirements and writing use cases

Question

A while ago I saw a Lynda.com course called "Foundations of Programming: Object Oriented Design" and the course guy gave a 5-step list to create a domain template:

• Collect requirements
• Describe the system (with use cases)
• Identify the main objects
• Identify the relationships between the main objects
• Make a class diagram

So far so good, I really liked the way he proposes to make the domain model, but I’m still very doubtful in the collection of requirements and the description of the system with use cases. Are there techniques for a programmer who works alone to do this successfully? There are also real examples?

I say this because I mostly work with web apps and intranets, but the examples I’ve found so far are about bank Atms and stuff like that. These are interesting things, but I wanted to see something closer than I work, so I could base myself.

Answer 1

Theory is beautiful, if it wasn’t theory.

in practice

1. you can never collect all the requirements of a system at the beginning of it, because the use of the system leads users to reflect on new uses, not counting the fact that they remember new details.

2. "agile" approaches will try to sell you the idea that you can stick to the customer and go extracting interactively the requirements, negotiating each delivery a set of features that "add value" (coff coff). I find it quite questionable that a customer would agree to pay for iterations without knowing what it will have at the end of a given term, perhaps hence the vast majority of contracts still remain closed-ended. I find it equally questionable that the client has the willingness to participate in the project as agility advocates, but it is worth trying. In practice, customers feel that guessing what he wants is part of the package he’s paying for, after all, it’s his time.

Since no system begins to be developed without an initial minimum notion of scope, and given that the approach of trying to collect as much specification from the start is not perfect by the dynamic nature of software engineering and given that agile approaches sell the correct idea that the customer should consider the software as a service development and not as a product that costs X to get ready with set price from the start, what we have left?

1. Identify early on what the MOST IMPORTANT features are and focus on them from the start, because if you’re late (and you probably will), it’s easier for the project to survive if the main features are implemented from the start
2. Get customer commitment to the requirements, formalizing them whenever possible and prioritizing, so you have some bargaining currency (vc will need)
3. Get from the start the system’s acceptance criteria, which are more important and define better what the system should actually do than the initial specification. In fact, if you can focus on the criteria of acceptance as the criterion where the project and payments end from the beginning of the project, so much the better. Otherwise, it indicates that your customer does not know well what he wants and that the project should be regarded as a service and not as a product.

UPDATE - just complementing, you asked for techniques. The most important technique is to know how to listen. And after a few good years, I realized that the best book I know to teach empathy and listen to is this book, which although it doesn’t seem to be applicable to software engineering, I think it’s perfectly possible. http://www.amazon.com/How-Talk-Kids-Will-Listen/dp/1451663889

Answer 2

I agree with Leo that theory is different from practice, and the whole answer is very good.

Theory vs Practice

We have to be careful.

Many theories are created to then be implemented and tested in practice. They may or may not work.

But in the case of Software Engineering, what happens in general is the reverse. Much of the theory came from the observation of practice or borrowed from other areas of knowledge, such as factory procedures or project management.

The problem is that these things don’t work the same way, after all you don’t develop software the same way you make an automobile on production lines or you build a building.

Analogies

Although they are not perfect, many analogies with these other areas help us to understand what we are doing.

Similarly, a step-by-step like the one described in the question does not consist of a fixed rule to be followed, but an abstraction of what is actually done.

In other words, it’s not like a cookbook or an assembly manual where you take each step and get the final product. Think about the Software Engineering theory about an attempt to explain or describe what we often do without even understanding.

Example

Suppose you had an idea for an internal system for your company that will improve a certain process.

You go to the person in charge of the area and ask some questions to understand how things really work.

Then go back to your desk and write a text telling you what the system could do to effectively improve the process.

Then you go back to talk to the person in charge and explain your proposal, that is, how you intend to make their work easier or effective, save effort, decrease errors, or anything along those lines.

Imagine that he liked the idea and tells you that he would be grateful to work with you to make it real.

At this point you go back to your desk and spend a day or two outlining your idea better, creating screen models, maybe modeling the database and, in the end, assembling a very simple small prototype,

Now you call the man in charge and show him what you’ve done. Imagine that he liked it, thinks he’s on the right track and just gives some tips on some details that would look better in another way.

Finally, you would spend another week or two to improve the prototype, polish the interface, put some security and make available the first version of the product.

The responsible one then starts to use with his team, verifies that the result was positive and from there he will begin to request some improvements, small adjustments and new functionalities to improve even more the gotten gain.

Explanation

All I described above trying not to use technical terms is exactly how a project could work using the same steps described in the question, but with an agile approach.

Note that even in the agile project you have the analysis of requirements, description of the system in user stories, think of the objects that will compose the solution and make these objects work.

The main differences are:

• It may not be necessary to spend a lot of time making diagrams to unless this is relevant to your understanding of the problem
• In the agile process we don’t try to figure out everything the system should do forever and ever, but focus on an initial idea that solves the most critical problem, test whether it works, get the feedback user and iterate again, that is, go back to the first step to create a new version of the system with better and more functionality
• The focus is on meeting customer needs and not simply creating a computational model and beautiful diagrams

Considerations

Use the concepts of Software Engineering to understand the principles of software development and then use the engineering or management techniques that contribute to improve your work.

Sometimes, when the work environment is chaotic, it is recommended to adopt some existing development model. But, in general, the ideal is not to try to follow a textbook but to adapt the available methods that are relevant in your case to then try to do a more effective job.

Anything that doesn’t work should simply be discarded. For example, I recommend you try to make a simple class diagram without spending too much time thinking about absolutely all possible relationships and attributes. After a while you will realize how much this diagram was useful or not and in the next cycle you will have more security to decide this.