Archive for the ‘Requirements Engineering’ Category

It is important for anyone taking the responsibility of requirements development to set a communication framework in order to organize and facilitate requirement gathering, classification, documentation and dissemination job.

This framework should include a communication plan, set of templates, set of textual and graphical models…etc.

It may sound self-evident, but I often find it necessary to start this effort by first agreeing with stakeholders on the definitions of terms we will use in describing requirements. I frequently find this basic step necessary due to the disparate professional and educational backgrounds of project team members, also because of the overloaded terminologies we use when we talk about requirements.requirements cloud

To reach this common understanding, I usually start the analysis meetings by presenting the terms from reference sources such as Karl Wiegers books and discuss them with the team to come up with agreed on definitions.

From the last time I did this exercise  the stakeholders group discussed the following set of terms : Scope, Constraint, Assumption, Acceptance Criteria, Business Requirements, User Requirements, Project Requirement, Functional/Non-Functional Requirement , Feature, Use Cases, Actor, Metadata, Scenario, User Story, Business Process, Business Rules, SMART Requirement, Activity Diagram, Interaction Diagram, BPMN, Context Diagram, Entity Relation Diagram, Priority, MoSCoW Requirements, Artifact and Deliverable.

Discussing and agreeing on the meaning of such terms and other terms specific to the business domain will lay the groundwork required for streamlined and productive requirements development engagement.


Read Full Post »

Just woke up from a coma 🙂 … no…really I had hectic few months …as usual…I was starting a project and work duties were hardly allowing time to my life…thank you very much…but…but… things are settled now …(you optimistic fool :)) …so I will try to find time to blog… no hard promises… but I will try…for now I have edited my last post “Rules Of Engagement” … I don’t know…it seems that I have changed my stand …I am now more willing to accept less customer engagement while eliciting requirements…yes…the theory is tested in the fire of practice … so I changed the tone of my post a little, visit it … if it is not much to ask.

C’est tout  and stay tuned!


Read Full Post »

According to IIBA BABOK Requirements are not gathered or collected but rather Elicited where Elicitation is defined as to draw forth or bring out.
This indicates that Eliciting requirement is an effort and customer engagement intensive process where a dialog is initiated between BA and Stakeholders and among stakeholders themselves to reveal the actual requirements and its details.
However, sometimes eliciting requirements by actively engaging the customer leads to scope creep!  Sometimes customer tends to behave as a shopper who wants everything and who pays only little attention to her credit limit.
In such situation another practical approach can be followed, basically  the BA should act as a consultant, an advisor who will draw only the high-level requirements, and actively scope them considering all constraints with a close involvement of only few people, then further detail them without really  going back to the rest of  stakeholders!
This approach is claimed to be more practical!  It might not be so customer engaging but it does not also neglect it all together.
The gain here is shorter time to requirements.
Having said that, following this approach may lead to discrepancies between the final product and what the customer wished to have, especially if the BA has little or no experience in the subject matter.
A number of check points during project life cycle need to be carefully planned to verify whatever assumptions BA has made during requirements activities.

Let me know what do you think?

Read Full Post »



I am still around!, I just had some demanding duties last month which sometimes can’t allow me time to blog, but here I am as good as new  🙂

Thanks to my friend and PTNet colleague Islam Ali, I knew about IIBA which is an association of professionals working in the field of Business Analysis with an objective of standardizing the Business Analysis profession practices.  IIBA has just published Business Analysis Body of Knowledge (BABOK) 2.0, they are also offering certification through rigorous process, similar to PMI PMP certification process.
I found that they have local chapters in Jeddah and in Cairo, I have registered for their membership, it is 95USD per year, which allowed me to download a copy of BABOK and watch some useful recorded webinars. Please check it for yourself  www.theiiba.org, I believe it is a community that worth participating in and whether you are or aspiring to be a project manager, a software architect, or a systems analyst you will definitely  learn something.

Take care,


Read Full Post »


Have you ever been in a situation where your sales team insists on adding more features into the proposal just to show muscles in a public bid that your company is participating in!
Competition is tough this is a fact but at the same time adding extras is a waste of effort and money. It doesn’t respond to customer needs and it is even not ethically justified, at the end there will be extra cost that the customer will pay and you will be charging for more than what you should. Project management standards call this Gold Plating.
User Requirements must be derived from business objectives whose source must be the customer needs.
But if your sales, sometimes your misinformed customer or anyone of the stakeholders, wants to add a requirement that you, as a requirements engineer, cannot justify … what shall you do?

I have raised this question to Karl Wiegers the Requirements Engineering authority and the author of Software Requirements, 2nd Edition.

And he kindly replied to me and agreed on posting his reply here,

Karl answers” I do think it’s a good idea to know where every requirement came from. One way to do this is to create an attribute called “origin” for each requirement. If you find requirements for which you cannot identify an origin, especially a customer- or business-related origin, then the project manager and other decision-makers should question whether it’s really a good idea to include those requirements. It will consume effort and resources to implement them, so there should be a good reason for them to be included. These are usually business decisions, not technical decisions. As a requirements specialist I would say that your main contribution would be to identify these questionable requirements and bring them to the attention of the appropriate decision-makers. They might still decide to include them for some reason, and you might or might not agree.

Another way to approach this is to use the requirements prioritization techniques I describe in chapter 14 in my Software Requirements 2nd Edition book. For each of these questionable requirements, ask whether its priority is high (must be included in the next release), medium (must be included eventually), or low (could be omitted if necessary). This analysis is based on the two dimensions of urgency and importance. I suspect you’ll find that some of those requirements are not important but someone (manager, sales, marketing…) thinks they are urgent. Such requirements can cause the team to invest effort without an appropriate payoff, which is not a good business decision. Sometimes marketing includes certain “checkbox features” that don’t relate to customer needs but there is a perception that those features need to be there for competitive reasons.

The requirements prioritization spreadsheet I describe could also be a useful tool to analyze the cost/benefit of each of these requirements so you can tell if it’s really worth including them.”


Read Full Post »