project scope management

Jamal's Musings – Who Is A Requirements Analyst?

So, who is the requirements analyst? He has to perform several roles at once. He has to be a translator, since he is responsible for capturing the requirements expressed in the language of the user or customer (typically a non-technical language) and translating it to the language understood by the technical project resources.


For example:


"The car must be really fast"


 converts to:


"The car shall be able to travel at a speed of up to 100 mph"


She has to be a keen observer, since she has to observe the work performed by the user from the user's rather than from the technical resource's perspective.


The requirements analyst has to be an interpreter of the work to be performed; in other words he should be able to reveal the essence of work, not its incarnation.


For example:


"The bottle opener must be rectangular in shape"


converts to:


"The bottle opener shall be able to open bottles with both round and rectangular necks"


Very frequently the requirements analyst is someone who invents better ways of performing the work described by the user.


For example:


“The dryer should have different drying cycles to accommodate for different types of loads”


converts to:


“The dryer shall have three different drying cycles (small, medium and large)”


“The dryer shall have a dryness sensor that will shut the device down once the laundry is completely dry”


Requirements analyst is also a scribe who should be able to record the results of her analysis in the form of stakeholder-understandable requirements specifications and analysis models that are necessary, verifiable, attainable, unambiguous, complete, consistent, traceable, concise and prioritized.


For example:


Jamal's Musings - Project Management in History: The University Construction

A government of one of the countries in the Gulf region decided to embark on a project of building a multi-campus university in several - at times remote - locations. It was decreed that the said project should take five years to implement and the cost should be around US$200 million. It is not completely clear even after talking to several people actually involved in the endeavour right from the very beginning whether these constraints were just "dropped" from the very top of the government levels or if these were at least a very high-level estimates generated by a qualified party.

The scope of the project, at least at a very high level, was also thought to be well-understood. It included the following requirements:

  • Engineering design of all five campuses (both conceptual and final)
  • Construction of classrooms and lab training facilities
  • Construction of dormitories
  • Procurement and installation of all necessary equipment
  • Setup of a new IT infrastructure including several data centers
  • Design, development and delivery for over100 new courses,
  • Setup and customization for a web e-learning portal

The primary contractor has decided to proceed with five different vendors to be responsible for different parts of the scope of the project. As a result, each vendor was requested to provide his version of the solution with respect to their vertical area of expertise. The primary contractor decided to simply aggregate individual scopes provided by the vendors into one united program scope. Consequently no thought was given to the proper integration between different scopes.

Finally, it turned out that the original RFP issued by the customer neglected to mention that the university will be constructed in an open desert with no water, electricity, sewage or roads. And since the primary contractor neglected to verify the existence (or absence, to be more precise) of all these ingredients, the budget and duration for the project mentioned in the original contract were, to say the least, inadequate.

Article: How To Define Scope on Software Development Projects: Functional and Non-Functional Requirements

The Story Of A2LL

A2LL – the German social services and unemployment software system was developed over the course of several years by T-Systems - a software department of state telecommunications company – along with ProSoz, a smaller company of about thirty developers located in the town of Herten.

The final product was delivered in the last quarter of 2004 and went live on January 1, 2005. The system consisted of the web browser front end, while the back end was based on 16 servers with 4 processors each.

Upon the deployment of the system at several large German cities including Cologne, Hamburg, Frankfurt and Berlin, the users at the welfare offices started reporting serious problems with the software.  Some of the problems encountered are listed in Exhibit 1.


Exhibit 1

System Bug Description

Type of Requirement

If data entered into the form was incomplete (e.g. someone missed one of the many questions) the system automatically deleted the record after about three or four weeks


Account numbers that were less than ten digits in length were filled with zeros at the end of the string rather than at the beginning (e.g. 3225223 became 3225223000 instead of 0003225223).



System was not capable of producing an “Analysis of Variance” report


System was not capable of producing a “Persons Who Received Too Much Money” report


System did not include the functionality to deal with the deductions for income from small jobs


News - “Project Scope Management” book to be released in the Fall of 2014

Just spoke to my publisher at the CRC Press. It looks like my new book “Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects” will be released in October of 2014.

The book page can be accessed here.

I will keep your posted regarding the updates.

P.S. The cover picture you see in this release has not been approved yet. Hopefully very soon I will obtain several cover versions produced by my publisher and we can vote on the best option. Looking forward to your feedback!


Jamals Musings – Requirements Elicitation Is Not Easy – Airline Check-In Kiosk

Let us review some of the questions an experienced requirements analyst will ask in the process of eliciting of requirements for this particular process. Let us assume that the key steps in this process are:

  1. Initiate the program
  2. Identify yourself
  3. Find the reservation
  4. Check visa
  5. Check in luggage
  6. Select seat
  7. Select meal

Here are some of the questions that may be asked just for the first three steps in the process (see Table 1):

Table 1

1. Initiate the program

What options will the user have to identify himself/herself?

2. Identify yourself

With a Passport:

  • Do all passports follow the same encoding standard?
    • If not, then how many standards exist?
  • What happens if the machine is unable to read the passport?
  • If the machine is able to read the passport what happens if:
    • Passport is real and not expired?
    • Passport is real but expired?
      • Will the user be issued a boarding pass if this is an international flight?
      • Will the user be issued a boarding pass if this is an internal flight?
    • Passport if fake?
      • Should the kiosk notify the police?
        • Does this mean that every device needs an interface with an airport police department?
        • Does this imply that we need to deploy some kind of software in the airport police headquarters?
      • What should the kiosk “do” while the police if being notified?


With a Credit Card:

Jamals Musings – Requirements Engineering compared with Project Scope Management

It is worthwhile to compare the requirements engineering process with the project scope management flow (see Figure 1).

Figure 1

As can be seen the “Collect Requirements” process corresponds perfectly to the “Elicitation” phase in the requirements engineering domain. The “Define Scope” process includes all of “Analysis’ and the beginning of the “Specifications” stage. Work breakdown structures are finalized once the “Specifications” phase is complete. “Verify Scope" and “Validation” correspond one to another perfectly, while “Control Scope” includes both “Requirements Tracking” and “Requirements Maintenance”.


This is an excerpt from my new book “Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects” that is being published by CRC Press The book should soon be available on Amazon.

Please leave your feedback in the “Add New Comment” section below. Also, feel free to share this article via Facebook, Twitter, LinkedIn or Google Plus by clicking the buttons at the top of the page.

About the Author

Jamal Moustafaev, MBA, PMP – president and founder of Thinktank Consulting is an internationally acclaimed expert and speaker in the areas of project/portfolio management, scope definition, process improvement and corporate training. Jamal Moustafaev has done work for private-sector companies and government organizations in Canada, US, Asia, Europe and Middle East.  Read Jamal’s Blog @

Jamal's Musings - Project Management in History: The Viking Longship

The Vikings were the Norse warriors, explorers and merchants who raided, explored and settled wide areas of England, Scotland, Ireland, Wales, Iceland, France, Spain, Africa, and Italy. They started their expansion by executing multiple raids of the English shores. According to the Anglo-Saxon Chronicles, Viking raiders struck England in 793 AD and raided Lindisfarne, the monastery that held Saint Cuthbert’s relics. Their raids continued to increase in frequency and the number of participating troops, until in 865 AD the Great Heathen Army led by the Brothers Ivar the Boneless, Halfdan and Ubbe Ragnarsson arrived in East Anglia and established their presence in the Northern England until they were driven out by the English king Harold Godwinson in 1066. The archeologists and linguists recently came to a conclusion that all British towns that end with "by" - for example, Ashby, Corby, Crosby, etc. - were founded and named by the Viking invaders.

Interestingly enough Harold lost the famous Battle of Hastings in the same year to another descendant of the Vikings (Normans) who settled in the Northern France a hundred or so years prior to the events, future king William the Conqueror (or William the Bastard as he was known before the battle).

According to the Russian "Primary Chronicle" three Viking - or Varangian as they were known in Russia - brothers Rurik, Truvor and Sineus were the first kings of the Russian royal dynasty that spanned from the 9th until the 16th century. And, yes, famous (or infamous) Russian tsar, Ivan the Terrible who was a last ruling member of the Rurikid dynasty can trace his roots directly to the Swedish warriors, who arrived in Russia almost seven centuries prior to his birth.

After establishing their foothold in Russia, many of the Vikings travelled South to the Caspian Sea and farther to the Byzantium Empire, where many of the enlisted in the much-feared Varangian Guard of the Byzantine Emperors.

In the XXI century a branch of the Norman royal family headed by the Roger I conquered Sicily and ruled there for the next two hundred years. Vikings also reached the shores of North America where Erik Thorvaldsson and his son Leif Ericson established several colonies in what is today known as Newfoundland.

Jamal's Musings - Project Management in History: The Katana Sword

Katanas, or as we also know them the samurai swords, emerged in Japan sometime between the 12th and the 14th century during the Kamakura Period. Historians believe that katana has replaced the longer and heavier predecessor tachi because it could be drawn faster, thus allowing the samurai to draw the sword and strike down the enemy in a single motion.

Katanas were extremely sharp; the sword was designed to cut through the iron-plated armour. The legend has it that the best katanas forged by Japanese blacksmiths could cut through four to five individuals standing next to each other in one single stroke!

Another legend claims that katanas were responsible for saving the Japanese from the Mongol invasion in 1274 when badly outnumbered Japanese warriors were able to hold off an invading army of Kublai Khan until their fleet was destroyed by a typhoon.

Modern weapons experts consider katanas to be the best cutting tools ever made by humans as they combine two unheard of before attributes: razor sharp and yet resilient blade that could withstand considerable blows. The eternal problem that the blacksmiths had to deal with for thousands of years before was the fact that the hard steel was very fit to be sharpened, but the tempering (i.e. heating followed by fast cooling) process left the steel very brittle and susceptible to breaking from blows.

On the other hand, the steel that has undergone a slow cooling process remains relatively soft and thus better able to withstand strikes without breaking, but loses the ability to maintain the sharp edge.

Thus the Japanese weapon makers had to deal with the eternal and seemingly unsolvable issue: how do we make the sword blade hard enough not to lose its edge when sharpened and yet soft enough not to break when struck by other weapons?

They came up with an ingenious solution to address this centuries-old problem. The first step involved selecting the best samples of low-carbon, soft steel and high-carbon hard steel available. The each piece is repeatedly forged by heating and folding it numerous times to create a layered structure and work out all the impurities.

Later a high-carbon band of steel is heated again and bend into a U-shape, whereas the soft, low-carbon piece is inserted into the center (see Figure 1).

Figure 1

Jamal’s Musings - Project Management in History: The Rusted Staple Story

Abwehr, the German military intelligence organization has been created in 1921 as a part of the Ministry of Defence. It remained small and consequently not very important part of the Wehrmacht until on January 1st, 1935 it was taken over by the soon to be Admiral Wilhelm Canaris.

In a fairly short period of time Canaris was able to reorganize his agency into one of the most efficient intelligence gathering organizations in the world.  Abwehr's activities spanned through the entire world including United States, Canada, Africa and Europe including England and Russia.

With the opening of the Eastern front Abwehr was tasked with establishing Abwehr schools on the occupied territories of Poland, Baltic states and Western parts of Soviet Union. These organizations were responsible for recruitment, training and deployment of commando-style agents whose primary purpose have been the reconnaissance and sabotage behind enemy lines.

The aforementioned recruits were typically hand-picked by the Abwehr officers among millions of Soviet POWs who were captured in the first several months of the invasion. Some of them were convinced to enlist in the intelligence schools because they could no longer bear the horrible living conditions in the German POW camps, while others did this for ideological reasons, not the least of which was the hatred of Stalin's tyrannical regime in Russia.

After undergoing extensive training that included hand-to-hand combat, target practice, interrogation and intelligence gathering techniques, as well as radio operations to name a few, the graduates were  supplied with absolutely the best documentation provided by  Abwehr's Department 1-G responsible for false documents, photos, inks, passports and chemicals. It is important to note that German technology of producing counterfeit documents was probably the best in the world at the time. After all, they mastered the production of British pounds and US dollars that perplexed the most experienced experts on either side of the Atlantic.

Jamal's Musings - Project Management in History: Burj Al Arab

The Burj Al Arab (The Arab Tower) hotel was built in 1999 in Dubai, United Arab Emirates. This project was conceived at the very top of the UAE government as a venture that would assist in transforming the country and the state from the exclusively oil-based economy to the trade and tourism-based market.

The ruling family of Dubai gambled – and by all accounts won – that the conversion into international hub of trade and tourism should start with a “wow-type” project that would demonstrate to the rest of the world that the Gulf country can:

  • Undertake ambitious projects and see them to completion
  • Has a rich cultural and historic heritage
  • Has the supply of and the demand for luxury hotel accommodations

The project that lasted for five years – from 1994 to 1999 – delivered a 321 m (1,053 ft) structure that is now the fourth tallest hotel in the world. Burj Al Arab stands on an artificial island 280 m (920 ft) from Jumeirah beach and is connected to the mainland by a private curving bridge. The shape of the structure is designed to mimic the dhow’s (type of local boat) sail. It is very frequently referred to as the world’s only seven-star hotel; although the company managing it refuses to even acknowledge the fact that they were the ones who started using this epithet.

Burj Al Arab is one of the most photographed buildings in the world and definitely played an integral role in putting both Dubai and the United Arab Emirates on the world map.

The purpose of this case study is to attempt to take this enigmatic and grandiose product and try to reverse engineer the requirement elicitation process from the few high-level business requirements to general features to detailed technical requirements. Let us start with what the business requirements for this project may have looked like (see Table 1):

Table 1


Requirement ID

Business Requirement Description

BR 1.0

Has to become a national icon for the UAE