Comparison of user centric requirements engineering techniques

I have been reading an interesting article in IEEE Software (March/April 2009). It is called Modeling Usage: Techniques and Tools. The authors discuss and give examples on the following methods:

Use Case
User Story
Problem Scenario
Use Scenario

In a simple table they highlight the pros and cons of the various techniques.

A draft version of the article can be obtained via Modeling Usage: Techniques and Tools.

Service-Oriented Architecture

Service Oriented Architectures are becoming a hot topic even for me. Although I have tried to refuse this new approach for a long time, by now I cannot find any reason to longer discard the matter. I bought my self a number of well reviewed books just the other week.

I like to share them with you:

Requirements Modelling and Specification for Service Oriented Architecture by Ian Graham.
This book provides as the title suggests a lot of information on what is required to become succesful with introduction of a Service Oriented Architecture. A lot of praticalities are provided.

Service-Oriented Architecture, Concepts, Technology and Design by Thomas Erl.
This book is supposted to be the bible on this topic. I have not opened it yet, but it size alone indicates that it covers probably everything you always wanted to know about Service Orientation (and more).

Moving from Software Architecture to Enterprise Architecture

Yesterday I visited a customer of ours. He showed me the possibilities of using Lattix together with Troux and in the mean time showed me more on Enterprise Architecture. So today I surfed some websites to get a better understanding of Enterprise Architecture.

In many cases Enterprise Architecture and Software Architecture do not differ much especially if you have at least some knowledge of IEEE1471 and the Views and Perspectives approach. Enterprise Architecture can be described by using different EA Frameworks. Since there are a lot I needed some comparison between those frameworks. I found a very nice whitepaper here.

This paper contains an introductory case in combination with the applicability of the frameworks in support of this case.

Scalabilty guidelines

Randy Shoup of E-Bay has written a very helpful arcticle on architecting for scalability. You can find his introductory article here.

Models for Evaluating and Improving Architecture Competence

Len Bass, Paul Clements, Rick Kazman and Mark Klein have written a very interesting technical report on Competences of software architects and organisations.

You can download the document from here.

Mindmaps

Problem area:

Mindmaps are especially useful in situations that are not particular clear. By making a mindmap one structures information and by doing so start to better understand the information. E.g. combining information found on different websites, but with the same focus point.

Mindmaps not only help to structure knowledge, but also makes it possible to better remind the information. Mindmaps are particular valuable when they contain less words and many images.

I use mindmaps in many situations. In many cases I use the technique as a starting point for a new document, planning, presentation or website. Mindmaps force you to structure the information you want to present. Basically I use mindmaps when I am not sure what to do next or approach new information.

Tool support:
For Mindmapping many tools are available. Some are free such as Freemind, other commercial such as Mindmanager and Mindmapper. For me tools that can export mindmaps to Word, PowerPoint or similar formats reduce the time to create a new document.

Concept maps

Problem area:

In cases that you notice that people within your team or with people outside your team are miscommunicating, for instance:

• because the concepts are unclear,
• the exact meaning of words differs from person to person, or
• a kind of project/domain glossary is lacking,

it is wise to start using a concept map. Making a concept map can be a good starting point for requirements gathering sessions/design sessions and so on. On the other hand making a concept map can be very helpful for you.

In a concept map nouns and verbs are connected to each other since verbs connect nouns. Nouns will become dependent upon each other and start to make sense. A concept map is a perfect way to start modeling (e.g. in UML class/ERD diagrams) afterwards.

I have used concept maps for more than one project. Basically I start to make concept maps if I want to get insight in a particular domain and want to find out if the team members and stakeholder have the same understanding of the domain (and mean the same with it).

Hierarchical concept maps (read pyramid shaped) are easiest to understand and easier to build (software) systems with. Focus of a concept map can better be on the domain layer or the datamodel.

Tool support:

A nice tool, called CmapTool, to use can be found at: IHMC with this tool it is possible to set-up a concept map server that enables teams to work on a single map. It supports auto-lay outing that is helpful when concept maps start to grow.

Currently I am not aware of other tools since in many situations this tool is doing what it is supposed to do, and it is free. You are welcome to introduce other tools here.

Interesting introduction to Software Architecture Refactoring by Dr. Michael Stal

I just saw an interesting movie on Software Architecture Refactoring by Dr. Michael Stal.
Michael Stal On Architecture Refactoring

Michael discusses the current state of refactoring, which is most of the time on code level or derived from code.

Michael also has a blog at blogspot.

Upcoming Seminar on Software Architecture in the Netherlands

Together with some partners we will organise a special one-day seminar that will demonstrate tools for visualisation of source code. Both vendor and user will present their findings and usage of these tools. A date and agenda is not set yet. Vendors and software architects that use these tools are invited and can contact me.

The tools should be useful to provide insight into architectural aspects as derived from source code. One can think about special visualisation, legacy reverse engineering, architectural control, etc.

The seminar will be targeted to experienced software architects only. The seminar will probably located in the vicinity of Eindhoven.

Viewpoints and Perspectives

Yesterday I was talking to a former colleague of mine. We were discussing recently read software architecture books. He showed me some heavy stuff about legacy refactoring. I adviced him to read the book: “Software Systems Architecture, Working with stakeholders using viewpoints and perspectives” by Nick Rozanski and Eoin Woods. This book is a great read and very helpful. The book is accompanied by a very informative website: http://www.viewpoints-and-perspectives.info. If you are a software architect struggling with various concerns of various stakeholders the theory and the practical advice of the authors might be very helpful to you. My former colleague bought it with one click.

I work with the IEEE1471 guidelines and the ideas of the 4+1 view for software architecture some years now, but the information provided by Nick and Eoin makes everything more tangible.