Update & Share tips on Testing, Develoment, Design & Other New Tech Trends

Post Top Ad

Post Top Ad

Tuesday, July 18, 2017

Thoughts on 7 Good Practices for Modeling Software Requirements


These are 7 “Good Practices for Modeling Software Requirements”:



I like the spirit of this. But for those who are in an Agile or XP environment, or for those who follow MSF, AUP, or other iterative frameworks, there are some things to consider. I am going to bring up some, but certainly not all, of these sorts of issues.

In regard to 1. BRUF (Big Requirements Up Front) is not only time consuming and costly, but often somewhat wasteful. Requirements change as your stakeholders and clients learn about what they are getting. Most of the time, as a software consultant, part of your job is to help the client realize their vision or solve their problem via technology. This is normally an iterative process whether you approach it that way or not. If you define scope as the 10,000 ft. view of the project (perhaps a simple Context Diagram), then I like this very much. However, the author of this chart suggests doing this to ward off scope creep. Scope creep is GOING to happen. If it is billable or not is one question, but if it is going to happen is another. It is going to happen.

Modelling software requirements analysis


In regard to 2. Again, I have stressed this elsewhere in my blog, but I believe that you use what is useful. Documentation can drown you fairly easily. Keep it light, Barely Good Enough, and malleable.

Recommendation for you :



In regard to 3. Repeat of #2. If your developers have no idea what a State Machine diagram is, you are going to have to work with what they do know. Most folks can get the hang of simple Activity Diagrams fairly easily. In my experience, you cannot throw all these models on the table and have everyone respond (in a positive way). New concepts need to be introduced slowly, and as they alleviate pain points. I have seen many a PM fail as they come to an organization with a portfolio of templates. Templates, even, usually need to be customized. We are lucky in this field; all of our tools are malleable. That is, unless you are using something like Rational, in which case you can find malleability within a gargantuan and robust legacy.

In regard to 4. I wholeheartedly agree, but wonder how this relates to the first item on the list. Your scope will speak to your requirements, and then, vice versa. This is iterative: RIP, JAD, what have you.

In regard to 5. This presupposes BRUF, to a degree, or at least some kind of system for documenting requirements traceability. Lots of places I have worked had MS Office as their PM tool suite (minus MS Project). You can do this with Excel (and I really like Excel for doing this), but it is time consuming and might not always be required -particularly if you are in an Agile or XP environment. The key here, I think, is in managing traceability and not breaking the thread.

In regard to 6. I like this one.
In regard to 7. There is not always time for this. At the end of each timebox or build, or at each checkpoint or milestone, there is often a sense of urgency. That is one of the reasons to implement an iterative development cycle; it keeps everyone from becoming complacent.

Read more about Sofware Engineering


No comments:

Post a Comment