Warning: include(api.php) [function.include]: failed to open stream: No such file or directory in /home/shapings/public_html/wp-content/themes/arthemia/functions.php on line 2

Warning: include() [function.include]: Failed opening 'api.php' for inclusion (include_path='.:/usr/local/php52/pear') in /home/shapings/public_html/wp-content/themes/arthemia/functions.php on line 2
Shaping Software » Requirements
Home » Archive

Articles in the Requirements Category

Design, patterns & practices, Process, Project-Management, Requirements »

[19 May 2009 | 6 Comments | ]
Customer Connected Engineering

Customer Connected Engineering (CCE) is a practices we use across our patterns & practices teams for engaging customers throughout the life cycle. We involved customers during the planning, development, and release of our deliverables. This is a draft slide set that shares how we do Customer Connected Engineering inside patterns & practices, including our key practices and guiding principles.

Architecture, Design, Requirements »

[2 Mar 2009 | 3 Comments | ]
Agile Architecture Method

The Agile Architecture Method is a way to bake quality into the life cycle. It’s also an iterative and incremental approach for architecture and design. In its simplest form, it’s a way to help you identify potential hot spots against your prioritized scenarios. The hot spots are key engineering decision. The main hot spots are cross-cutting concerns, such as data access, exception management, logging … etc. and quality attributes, such as security, performance, reliability … etc.

Project-Management, Requirements »

[11 Oct 2008 | Comments Off | ]
What’s a Scenario

Photo by Wonderlane
What’s a scenario?  Not everybody uses the term “scenario” the same way.  In the software industry, there’s three common usages of scenario:

The same as a use case.
A path through a use case.
An instance of a use case.

Usually, the most helpful one is “an instance of a use case.”  Why?  Because if a scenario is an instance of a use case, then it’s testable with concrete data.
 

Lessons Learned at Microsoft
At Microsoft, when there’s a customer challenge to solve, it’s common to ask “what’s the scenario?”  This …

Requirements »

[4 Oct 2008 | Comments Off | ]

What are five common project situations for writing use cases?  In Writing Effective Use Cases (Agile Software Development Series), Alistair Cockburn identifies five different situations for writing use cases to help you better understand variances between the purposes and approaches.
Five Project TypesCockburn identifies the following five particular situations:

Eliciting requirements, even if use cases will not be used at all in the final requirements document.
Modeling the business process.
Drafting or sizing system requirements.
Writing functional requirements on a short, high-pressure project.
Writing detailed functional requirements at the start of an increment, on a …

Requirements »

[9 Jun 2008 | Comments Off | ]

I’ve often run into debates over whether it’s worth distinguishing between user requirements and system requirements. I would argue that having precision around the perspective helps you make more effective trade-offs, as well as make sure you’re looking through the appropriate lens when you need to. In Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle, Ian F. Alexander and Neil Maden write about distinguishing between user requirements and system requirements.

Architecture, Frames, Performance, Requirements, Security »

[1 Jun 2008 | One Comment | ]

I found an organizing frame for quality attributes (security, performance, … etc.) on SoftwareArchitectures.com and I think it’s helpful.  They organize quality attributes by the following:

Runtime system qualities
Non-runtime system qualities
Business qualities
Architecture qualities
Domain specific qualities.

Quality Attribute Frame
This table shows an example of some quality attributes organized by the Quality Attribute Frame

My Related Posts

Quality Attribute List

Architecture, Performance, Requirements, Security »

[1 Jun 2008 | 3 Comments | ]

When thinking about quality, I tend to draw from the following quality attributes:

Availability
Buildability
Conceptual Integrity
Evolvability
Extensibility
Functionality
Implementation Transparency
Integrability
Interoperability
Maintainability
Performance
Portability
Reliability
Reusability
Scalability
Security
Serviceability
Subsetability
Supportability
Testability
Usability

Requirements »

[1 Jun 2008 | 2 Comments | ]

The most effective way I’ve found to elicit requirements, is to simply ask:

What are the user goals?
What are the business goals?
What are the system goals?

I like to follow on by asking about the boundaries (constraints) for goodness and the tests for success.
User, Business and System Goals
The user goals address user experience, the business goals address business value, getting the job done, and compliance, and the system goals address things like manageability, maintainability, evolveability, integration … etc. In all cases of course, there’s flavors of quality attributes, experience, and service levels …

Requirements »

[1 Jun 2008 | One Comment | ]

When Ward Cunningham was on our patterns & practices team at Microsoft, he would talk about “shifts of power.”  What’s interesting is how requirements perspectives both reflect and shift power.

“User” is king on the Web.  This is because they have choices, so the non-functional requirements / experience are competitive advantages. For example, if an application is faster, more reliable … etc. then you use it.
“Business” is king in the corporate Line-of-Business applications space. Users don’t have a choice. “User” experience takes the hit — bad performance, bad UI (User Interface)… …

Requirements »

[1 Jun 2008 | 4 Comments | ]

I was trying to find a way to express requirements from multiple perspectives, but keep it simple enough not to lose big ideas that matter.
It might be easier if I simply use:

Functional
Non-Functional
Technological
Constraints

(Note on non-functional — I hate “non-functional”– what are “non-functional” requirements? — yuck! — I think it should be more like “experience” or “quality”/”quality of service.”)

Requirements »

[28 Apr 2008 | 7 Comments | ]

I use scenarios all the time for anything from designing a user experience to evaluating architecture. Scenario is an overloaded term though. There’s lots of types of scenarios. If you know the types of scenarios, you can use the right one for the job. For example, exception scenarios are useful for assessing robustness. Misuse cases are helpful for figuring out potential threats and attacks.
Summary Table of Scenario Types
In the book Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle, Ian F. Alexander and Neil Maiden write about the types of …