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 tagged with: Requirements

Project-Management »

[11 Oct 2008 | One Comment | ]
Scenario and Feature Frame

A Scenario and Feature Frame is a quick way to show your project’s incremental value and dependencies.  It’s helpful for showing your management what you’ll deliver in terms of a baseline release.  It’s helpful for you in terms of finding ways to reduce dependencies.  If you have a bunch of scenarios that depend on certain features, then you don’t have cuttable scope.  The key is to find ways to factor your scope into incremental value.

Scenario and Feature FrameA Scenario and Feature Frame is a powerful tool for analyzing …

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.

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.”)

Architecture »

[12 May 2008 | 5 Comments | ]

I find it’s always helpful to think in terms of user, business and tech.  For example, whenever I see a product design or requirements, I walk through the user perspective, the business perspective and the technical perspective.  A lot of times, the business or technical perspective ends up winning because the customer didn’t have a voice.  Mistakes like that give software a bad rap.  After all, the software is for the user, isn’t it.   If your software doesn’t make the user more effective and more efficient, or worse, makes them …

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 …

Modeling »

[30 Mar 2008 | 2 Comments | ]

How can you quickly determine whether a recommendation or technique is relevant to your context?  You can use context-precision.  Context precision is simply a set of categories that help clarify the context.  I use context-precision both for creating more relevant guidance and for evaluating the relevancy of guidance.
Example
Here’s an example figure I draw on a whiteboard or use in slides when I need to show context-precision.

Categories for Context
Here’s an example set of categories:

Application Type: Web application, Web service, component/library, desktop application, mobile application
Deployment Scenario: Intranet, Extranet, Internet.
Project Type: In …