Comments on: Foundation Series: Structured Requirements

By: Casos de Uso, Requisitos Funcionais e Probleminhas » finito

Casos de Uso, Requisitos Funcionais e Probleminhas » finito — Wed, 14 May 2008 16:38:51 +0000

[...] variações em torno desta visão são curiosas. Tyner Blain, por exemplo, parte de uma uma sugestão de Karl Wiegers para gerar a visão representad…. Mas, caramba, não vejo ninguém afirmar com todas as letras que “passos em um caso de uso [...]

By: Raj

Raj — Mon, 31 Dec 2007 20:57:27 +0000

Hi Scott,

You are correct, 600+ is too much to read over a long weekend! :)

I made some good progress though – excellent blog you have here, keep up the great writing…

By: Scott Sehlhorst

Scott Sehlhorst — Sat, 29 Dec 2007 21:00:21 +0000

Hey Raj, thanks for the comment and welcome to Tyner Blain!

Good luck reading all 600+ articles over the holiday. That’s too much for me – let us know if you make it!

By: Raj

Raj — Fri, 28 Dec 2007 06:15:31 +0000

Hi Scott,

Just found your blog. This article is an excellent introduction into how to think about requirements. I agree that Karl Wiegers’ book is a must-read for anyone involved in requirements management.

I look forward to reading the rest of your blog during this holiday break!

Happy holidays,
Raj
Accompa – Affordable Requirements Management Software

By: accidental business analyst » Blog Archive » Not Everything Is a Use Case

Thu, 05 Apr 2007 19:01:57 +0000

[...] Use cases are derived from user goals and use cases drive requirements. In the context of a web application, a user goal might be to search for a CD to purchase. That would give us a use case that would be called ‘Search for CD’, or maybe something more broadly titled in the case of an Amazon like site ‘Search for Product’. Of course, it isn’t long before someone suggests an advanced search feature, so we have to decide whether that constitutes a new use case or an alternative path to the existing use case. Then someone suggests tools tips would be helpful and another suggests a breadcrumb trail. So, are these things that are included in an existing use case or do they constitute their own use case? [...]

By: Scott Sehlhorst

Scott Sehlhorst — Sat, 27 Jan 2007 04:12:38 +0000

We've just updated this article to reflect our refined perspective on structured requirements. A lot of search-engine traffic makes it to this page, and we reference it a lot to provide context to many other discussions. When we spent some time focusing on non-functional requirements, we realized that they are under-utilized, under-appreciated, and under-represented. Generally, they are under-valued. We believe this is because they lack obvious champions. We've refined our diagram to reflect the sources that drive non-functional requirements, in order to give them those champions. We covered this in more detail in our article, Non-Functional Requirements Equal Rights Amendment. Since this article is over a year old, our feed subscribers and regular readers won't know that it has been updated. At least those of you who subscribe to our comments-feed will know. Thanks to all who read this, and welcome to Tyner Blain if you're new here. Let us know what you think of this and other articles. Comment and join in the discussions, or at least rate the articles.

By: accidental business analyst » Blog Archive » Functional Requirements and Nonfunctional Requirements and Constraints… Oh My!

Tue, 20 Jun 2006 20:24:54 +0000

[...] Scott Sehlhorst at Tyner Blain has a great article about structured requirements. He simplifies Karl Wiegers’ ideas into a great little chart: [...]

By: Requirements vs design - which is which and why? -Tyner Blain

Requirements vs design - which is which and why? -Tyner Blain — Sat, 11 Feb 2006 19:43:11 +0000

[...] Product requirements. In a process that uses structured requirements, these are the functional requirements, user requirements and business requirements. Design constraints are also requirements (non-functional requirements). Product requirements can be captured in an FRS, SRS, or PRD. [...]

By: Writing functional requirements to support use cases -Tyner Blain

Writing functional requirements to support use cases -Tyner Blain — Fri, 10 Feb 2006 13:46:55 +0000

[...] 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. [...]

By: Prioritizing requirements - three techniques -Tyner Blain

Prioritizing requirements - three techniques -Tyner Blain — Thu, 02 Feb 2006 04:55:06 +0000

[...] Prioritize requirements based upon their explicit impact on profitability. With requirements traceability, we can break down the impact of supporting requirements as a percentage of the impact of those requirements that they support. This represents implicit value for a particular requirement. This is one of the benefits of using a structured requirements framework. Also, when using composition in requirements, we will distribute the impact assessment to the sub-requirements. [...]

By: Describing the software development process -Tyner Blain

Describing the software development process -Tyner Blain — Mon, 30 Jan 2006 02:28:43 +0000

[...] Requirements. Different processes will use different names for these. In a process that uses structured requirements, this is the functional requirements, user requirements and business requirements. These can be captured in an FRS, SRS, or PRD (but please no, not all three!). [...]

By: How to manage data when writing requirements -Tyner Blain

How to manage data when writing requirements -Tyner Blain — Sun, 29 Jan 2006 05:19:10 +0000

[...] [C1] Additional user interaction will not be required to display the city forecasts. {This constraint affects requirement [R1]} [...]

By: Telescopes, microscopes, and macro-scopes – how to view requirements --Tyner Blain

Tue, 24 Jan 2006 03:51:04 +0000

[...] When functional requirements are described too abstractly, they don’t provide enough information for implementation teams to properly scope the project. They also introduce too much risk – risk that the delivered product will not meet the needs of the stakeholders. Some examples: [...]

By: Tyner Blain » Where bugs come from

Tyner Blain » Where bugs come from — Sun, 22 Jan 2006 21:15:45 +0000

[...] The process starts with stakeholders (all beneficiaries of the software system to be deployed, including users) identifying their objectives. [...]

By: Scott Sehlhorst

Scott Sehlhorst — Fri, 06 Jan 2006 02:29:53 +0000

Thanks Kristina for the comments. In really liked the sample pages for Suh’s book at amazon (added to Tyner Blain’s bookshelf).

He used a simple description of the design process:
A. Know the customer’s needs
B. Identify the problem to be solved
C. Create a solution idea
D. Analyze the idea
E. Test that the design (C) meets the needs (A)

This is consistent with the high level view of software processes identified in the foundation post on software processes:

1. Decide what to do (combines A & B)
2. Do it (combines C & D & E)
3. Deliver it

I’m excited to see how he treats the transitions from A to C. And I wonder if the design-complexity issues he raises are consistent with trying to avoid entanglement in OO design. Thanks for pointing out his book to us, and keep on commenting.

By: Kristina Kuest Mistry

Kristina Kuest Mistry — Thu, 05 Jan 2006 17:25:13 +0000

This format is very reminiscent of Nam Suh’s Axiomatic Design. Functional Requirements (FRs) define the set of goals that the design must satisfy. Design Parameters (DPs) are the means that solve these goals. By mapping these parameters and establishing their relationships, the proposed system can be classified as coupled, uncoupled, or decoupled. There are two central axioms in Axiomatic Design: 1) Independence of FRs and 2) Information (minimize design complexity).

I attended Suh’s class at MIT and relied on these techniques heavily in my thesis. One great aspect of this work is that it is applicable for all industry. For more details, read his book “Axiomatic Design.” Understanding the underlying theory of this methodology can enhance your problem solving skills.