Warning: include(api.php): 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(): Failed opening 'api.php' for inclusion (include_path='.:/usr/local/php55/pear') in /home/shapings/public_html/wp-content/themes/arthemia/functions.php on line 2
Shaping Software » Scenarios
Home » Archive

Articles tagged with: Scenarios

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 …

patterns & practices »

[15 Sep 2008 | One Comment | ]
patterns & practices Solution Engineering

This is one of my favorite figures that shows how we do solution engineering in patterns & practices at Microsoft:
 
Architectural Scenarios
It all starts with a scenario.  It has to be a meaningful problem.  You can’t evaluate an architecture in a vacuum.  In order for us to build useful baseline architectures, we need to pick the right scenarios that flex the right engineering decisions.
Patterns
Patterns are simply problem and solution pairs.  In our case, we tend to focus on application, architecture or solution level patterns.
Baseline Architectures
Baseline architectures are skeletal applications.  They’re just …