Articles in the Requirements Category
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 »
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 »
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 …
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 …
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 »
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
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 »
When thinking about quality, I tend to draw from the following quality attributes:
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 …
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)… …
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:
(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.”)
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 …