Software Requirements Cookbook
Does a Requirements Development Roadmap Conflict with the Agility? In response to comment by Essam Badawy
by Dahlia Biazid on 11/14/11
It should not; and why would it?
Requirements roadmaps are concerned with picturing the building blocks (the mold) of a software system and the logical shortest (and perhaps most enjoyable) route to analyze and design these blocks, which eventually leads to the building of the system itself.
Suppose you hire a company to build a seaside resort. With regards to the components of the resort: the swimming pool, the gym, the hotel, the garden, etc; would it really matter if they will deliver the complete resort on one or two phases (waterfall), or if they deliver it piece by piece (agile)? At the end of the day, they need to analyze your needs, then design and build a resort that meets those needs.
How many rooms you want? Do you want all hotel rooms to have a sea view? Where you want the swimming pool location: close to the sea or to the hotel? Should the gym have a view on the garden? These are the needs a requirements engineer must explore, analyze, and ensure are met in the design and hence the final product; regardless of when the questions were asked – all at the beginning, or iteratively when it was time to build a particular component.
Furthermore, even in the most agile context, the vendor will still need to examine your vision, propose some sort of a high-level design that can be detailed later, and perhaps also present you with an initial plan that may be divided on successive iterations as needed; so both of you can have some confidence that there is a common understanding of at least your initial needs. You may change your mind along the way and decide that you can have some hotel rooms without a sea view after all, or that you want to add huts or chalets outside the hotel; but that does not deny the fact that someone from your vendor’s side have had to ask you these questions or to the least help you think of them in some way.
The Need for a Recipe
by Dahlia Biazid on 11/09/11
Everyone knows what use cases are and their use in the software requirements process. We all know there are many ways to write them: logical, physical, to describe a manual procedure or an automated procedure. The purpose of State Diagrams is well-known to everyone in the field. They help us define the transitional lifecycle of an object moving and manipulated on within a system. Data dictionaries are important to describe the elements of each data entity or class. And so on.
It is like a toolbox to choose from. I could use the hammer to bang on a nail (its original use), or to open something (an innovative use). In my requirements projects (or rather sub-projects form software development for that matter), I can use any or all of these techniques to analyze the system at hand. The question is when? What is the best strategy to employ these tools and get results most efficiently and effectively?
Nevertheless, this question did not seem answerable; even worse, it was not even asked! Instead, I looked around for a sample deliverable or a template to follow, with the hope that they would give me a picture to visualize and help me put the pieces together; and hopefully relieve me from the need to have a “strategy”. The tactic worked to an extent, but not completely. I still did not know for sure which step to make at each time I went to see the client or sit to think about the requirements plan. Only until the project was complete was I able to see the picture. So naturally, I took longer than I should to complete requirements; and the results were not as satisfactory as I as well as everybody involved wished for.
What was missing was the method, the strategy, the cunning of a chef who knows which ingredient to add and the exact timing and portion. What was really missing - and seems to be still missing - is the "recipe".
Learning Requirements Engineering
by Dahlia Biazid on 11/09/11
When I, as most novice analysts, learned Systems Analysis a few years ago, I was introduced to a pool of interesting techniques; each with its intrinsic aim and application, its logical outcome, and its added value to the process of requirements engineering [Engineering is used here in its narrower sense, which is requirements development not including management; it is still used to convey the sense of crafting].
Similar to learning Psychology, we were introduced to a variety of theories proposed by different scholars. That in itself was both beneficial and exciting, but not enough. We were still left with a central question unanswered: How do I approach a requirements project? Where do I start and end? How do I know if I completed my task – or at least made a complete attempt at covering my area end-to-end? As a beginner analyst, I needed to dig in the exciting - but disconnected - techniques and pick and choose to fit in the situation at hand.
Unlike Psychology and its focus on the human complicated nature and intertwined elements, Requirements Engineering is about crafting a tangible deliverable (the requirements document) and producing a product (the software application). If requirements engineering is really going to become “engineering” then there needs to be more structured methods, procedures that analysts can use, if needed.
With time I managed to create my own roadmap, which is the subject of the blog and the idea of an in-progress book.
