I am working on moving my blog to wordpress and as part of the effort I am cleaning up and rearranging some of my older posts. Since my readership has increased substantially compared with the time I started blogging I think some of them are worth republishing. I think that the series on SPAMMED, my software architecture meta-framework falls under the category.

Overview
There is very little guidance on how one can go about designing/developing an architecture for a software project. The SPAMMED architecture framework (SAF) aims  to help fill this gap. SAF  is a set of activities that an architect can follow when she sets out to design an architecture. These activities helps the architect to keep abreast of the project's needs and the drivers that affect the architecture. The Activities of SAF include

• Stakeholders -identify the stakeholders   - Anyone with vested interest in the project (end users, clients, project manager, developers etc.) These are the people you will have to explain you architecture to. These are the people that have concerns that the architecture will have to satisfy (or most likely balance). Thus, the fist step is to identify and rank them.
• Principles – list Principles, Goals and Constrains. These are the properties you wishyour architecture to have (or lack) based on your previous experience. Constrains can also come from your stakeholders (e.g. management decided that all project should be .NET, a deadline etc.)
• Attributes –  discover quality attributes, the non-functional reqeirements, that (once prioritized) serve as the guide for the overall goodness of the system (Performace, Availability, scalability etc.)
• Model – model (and document if needed)  the architecture as seen from different viewpoints (list of viewpoints is stakeholder driven). Example for viewpoints include package diagrams, deployment diagrams, DB Schema etc. etc.
• Map – Technology mapping, buy vs. make decisions etc.
• Evaluate – Since architecture is the set of decision that are hardest to change it is worthwhile to spend some time trying to evaluate if they are indeed correct before commencing on
• Deploy – Software architectures are not a fire and forget thing. As an architect you still have to make sure that the guidelines set are indeed followed and even more importantly that the architecture chosen indeed match the project’s needs and doesn’t have to be reworked.

Download the SAF introduction presentation (pdf) or watch it on slideshare You can also  read the DDJ article and read all the posts I made on the subject here :

• Getting SPAMMED for architecture
• SPAMMED State chart
• Stakeholders Everywhere
• P is for Principles (and Guidelines and Constraints...) - Iteration I
• P is for Principles (and Guidelines and Constraints...) - Iteration II
• Quality Attributes - Introduction
• Utility Trees - Hatching quality attributes
• Architecture & Functional Requirements
• Architectural Modeling - First Step
• Architectural Modeling - Choosing your Viewpoints
• Modeling - Architectural Styles
• SAF - Mapping -Don't forget the Technology
• SAF - Architecture Evaluation (Introduction)
• SAF - Architecture Evaluation - Evaluation in Code
• SAF - Evaluation part II - the "Formal Methods"
• SAF - Deployment - What to do when the architecture seems stable?

 

A while ago I wrote about use cases and user stories and how I use both, starting with user stories for ease of estimation and manageability and expanding them into use cases as a way to elicit more requirements.
I just read a recent blog (wiki) entry by Alistair Cockburn (of "writing effective use cases" fame) called  "why I still use use cases".
Alistair explains that he sees (with companies he consults to) three main problems with user stories:
    1. lack of context (what's the largest goal)
    2. sense of completeness - that you covered all bases relating to a goal.
    3. no mechanism for looking ahead at upcoming work.


I think the first reason is partially dealt with by using themes, although use cases provide more context if we also consider the brief description, pre conditions and post conditions.
Also I am not sure I agree (maybe I don't understand) the third one - since you can have a backlog of future work regardless of the requirements methodology you use.

The second point, seems to be around  the same reason I have for using use cases - elicitation of requirements. Indeed, you can see that reading reasons 3 and 4 (of the 5 reasons Alistair  mentions for still using use cases) :

"
3. The extension conditions of each use case provide the requirements analysts a framework for investigating all the little, niggling things that somehow take up 80% of the development time and budget. It provides a look ahead mechanism, so the customer / product owner / business analyst can spot issues that are likely to take a long time to get answers for. These issues can and should then be put ahead of the schedule, so that the answers can be ready when the development team gets around to working on them. The use case extension conditions are the second part of the completeness question.

4. The use case extension scenario fragments provide answers to the many detailed, often tricky business questions progammers ask: "What are we supposed to do in this case?" (which is normally answered by, "I don't know, I've never thought about that case.") In other words, it is a thinking / documentation framework that matches the if...then...else statement that helps the programmers think through issues. Except it is done at investigation time, not programming time. "

Alistair also says that working with short iterations means you have to break the use case into stories :

These days, iteration/sprint lengths are so short that it is not practical to implement an entire use case in just one of them. That means additional work is needed, to create user stories or backlog items for each use case, track that each one get developed, and ensure that the complete set of user stories or backlog items do indeed deliver the subset of the use cases needed for the particular release.

I think that working just from the use case toward stories  is limiting, since it is many times easier to think up a user story and figure out the larger context later on (along with the other details of the use case). Also, as I've mentioned in the above mentioned blog entry, user stories are also easier to estimate not just easier to build.

 

Jeremy D. Miller writes that he prefers user stories better than use cases - and I basically agree with him. Mostly because user stories are finer grained which lends to make them more "estimateable"  and manageable then use cases are.

However, having used both, I think there's one thing use cases do better then user stories which is eliciting related scenarios. When you write a use case that covers a  business scenario the use case template makes you think about variations and exceptions. When you try to think of a theme of user stories if you're not careful to do that in a structured manner you may miss some.

One important point regarding use cases is that you don't have to treat the use case a single monolithic block. When you work with use cases it doesn't have to mean that you sign-off use cases in a waterfall-ish manner- that is something that has to do with your development methodology.
You can develop use cases incrementally i.e. only do some of the use cases per "release". You can also elaborate use cases   iteratively by only elaborating/identifying some of the scenarios in each iteration (in a manner similar to user stories). I have successfully use both incremental and iterative use case elaborations  on several projects and I find it very useful (I even wrote paper summarizing my use cases experience a few years ago (warning - more than 60 pages with the examples and all..)

In fact, even today I find it useful to use both tools where I would usually start with identifying a user story and writing that down. Then map it to a use case (either existing  or a new one) - where a use case roughly equals a user story theme. As I mentioned previously I can them identify more user stories and add them to the product backlog. The use case stays a skeleton with links to the user stories and helps provide more context to individual use stories (ok, so that isn't a use case in the traditional sense, but I find it useful anyway).

Generally speaking, it is important to note that while it is tempting to equate a user story with a scenario in a use case, that isn't always true. sometime a user story would be a step in a use case and sometimes a story is shared by several use cases - since a fine grained feature that delivers business value is can be used in many business processes which is what use cases are oriented to


As a side note, if you have a project where you do have to write all the requirements up-front (as if they won't change anyway...) then I find that use cases are way superior than IEEE 830 style requirements ("The system shall...")  - but hey, that's another story :)