Author mmurphy

Reliability Requirements

Reliability is an important non-functional requirement for most software products so a software requirements specification (SRS) should contain a reliability requirement, and most do. But, one of our indicators of the quality of a ‘good’ requirement is that it is testable, so it is reasonable to ask whether the reliability …

Read More

The State Machine Diagram

One of the challenges faced by requirements analysts is the need to communicate the complex behavior of systems in an understandable yet rigorous and verifiable way. A significant amount of the effort in the requirements process is devoted to translating the users’ needs and goals from ‘the language of the …

Read More

Fun with CRC cards

Use cases have become an indispensable tool for requirements elicitation and documentation. They have the advantage of being relatively easy to write and, if written well, they are relatively easy to read and understand. This advantage comes in part from the fact that they are created using ‘natural’ language text. …

Read More

The Magical Number Seven

This story may sound familiar to you. A man decides to go to the store one Sunday morning to get a newspaper. Being the thoughtful husband he is he says to his wife “Honey, I’m going to the store for a newspaper, is there anything you need?” She replies “Oh, …

Read More

Are you listening?

Requirements elicitation is fundamentally about communication. We gather requirements from people who know what is needed or can help us figure it out. There are other ways to find requirements but elicitation is the most effective way in most cases and is almost certainly a significant part of the requirements …

Read More

Agile Development

Someone asked me the other day about agile development. Should we do it? Can we reduce the time we spend on requirements if we are doing agile development? Is it only good for some kinds of projects? If you’re reading this blog there is a good chance you know about …

Read More

Peeling the Onion

A common piece of advice given to teams starting out to document requirements is “Find the actors and use cases”. Sounds like reasonably good advice, but how do we find the actors? Well, actors are stakeholders, a subclass of the stakeholder class if you will. Not every stakeholder will have …

Read More

Where to start with use cases

We frequently find that software development teams defining requirements with use cases face a challenge in finding the right level to target as a starting point for their use cases. There is no widely agreed upon standard and team members often have differing opinions based on their background and experience. …

Read More