Software Requirements – Process and Roles

Posted on:

Our previous post, Requirements vs design – which is which and why, describes our position on which parts of the software development process are requirements-activities, and which parts are design activities. The debate among professionals about these distinctions is ongoing, and continues in the comments on that post. The length of the debate, combined with the skills of those debating demonstrates that it isn’t a black and white issue.

In this post, we will try and explore the reasons why this debate is ongoing. We will do that by exploring the symbolism of the terms involved, as well as the roles of different members of the software development team.

Symbolism and Communication

Posted on:

Symbolism and communication
One of the challenges in successful communication comes from the way people use symbols as part of the organization of their thoughts. Symbolic thinking and reasoning is an incredibly efficient process. It allows us to create representational views of the world that allow us to process much more information than our brains have evolved to handle.

What does this have to do with requirements?

We see from our earlier post on requirements gathering techniques that communication is central to the most important requirements elicitation methods. Understanding how people associate ideas symbolically helps us communicate more effectively.

Requirements vs Design – Which is Which and Why?

Posted on:

A classic debate. It comes up often. Unfortunately, it’s a source of confusion that causes many teams to shy away from staffing, creating, or managing any formal requirements processes. There’s a discussion on Seilevel’s forum where this has been brought up again, and it’s shaping up to be a fine grudge match here in Austin. We can’t let the other folks have all the fun, so we’ll chime in too.

Writing Functional Requirements to Support Use Cases

Posted on:

Background:

In our previous post, Sample use case examples, we created two informal use cases. The use cases were written to support product requirements defined as part of a project to reduce test suite maintenace costs. In this post, we will define functional requirements that support these use cases. This process is an example of using structured requirements, applied to a small real world project.

Sample Use Case Examples

Posted on:

We talked about informal use cases a while ago in our use case series. Over a series of posts, we are demonstrating the process of defining a software product. The next step, and subject of this post, is the creation of informal use cases to support the defined goals for the software.

Outside reading: Enterprise versus consumer software

Posted on:

Cote’ recently posted a good comparison of the features of Enterprise Software versus Consumer Software. Although we may not agree with all the items in his lists (consumer software can have a login, and very often does have upgrade paths), we do appreciate the general classification. And we really like his insight:

Outside reading: correlation and causality

Posted on:

A while ago, we asked you to send us links to good blogs. Jeff Kinsey sent us a link to his blog, Ski’s throughput on command. We found this post on logical thinking processes which is good. Thanks Ski for sending us the link!

Their post discusses the differences between causality and correlation of events.