requirements engineering

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 @ www.thinktankconsulting.ca

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

Business

Requirement ID

Business Requirement Description

BR 1.0

Has to become a national icon for the UAE

Jamal’s Musings – What is Wrong with Project Scope Management?

An observation of project management practices in various industries confirms that in many instances the scope management in general and scope definition in particular ends to be viewed as exclusive technical areas, which leads to several of very legitimate questions frequently asked by many of my colleagues:

  • "If the project manager is to lead the project should he also lead the product definition stage?"
  • "If scope size and complexity have a direct impact on project timing and budget, shouldn't the project manager be aware - at least a high-level - of how the technical team arrived at the current scope in order to be able to make trade-off decisions?"
  • "Our engineers (designers, developers, architects, etc.) are very good at design, but not very skilled at interacting with customers and extracting the requirements from them. What should we do in this scenario?"

Finally and most importantly, what about enterprise or multidisciplinary projects? With the size and the complexity of projects growing it is not unusual now that the project scope encompasses the entire organization. Let us look at a couple examples from different industries. Note to the reader: these are the two of the five projects we will analyze in detail and create project scope management documentation for throughout this book.

Port Authority - The Container Terminal Construction Project

The first one is the - as it was initially labeled by the senior executives - "construction of the new container terminal" project. The logic at the top of the port authority literally was, "since this is a construction project, there is no need to worry on our end; we will just outsource the construction part to the contractor."

Jamal’s Musings – Requirements Elicitation Is Not Easy - ATM Example

Let us consider an example that is very familiar to practically all the readers who at least once in their lives used and ATM to withdraw money, deposit cheques or pay their bills. Here is a very provocative question, does the reader (especially those not familiar with application development) think that creation of the ATM software is an easy or a very complicated project? Typically the answer - just as in the case with the airport check-in kiosk - is that this project shouldn't be too complicated. One inserts his card into the slot, enters his PIN and gets the money. These are seemingly simple tasks that we have done numerous times, but let us examine them step by step (see Table).

 

Identify yourself

  • Is it one card per account or can the user have several accounts linked to one card?
    • If yes, then who will create and administer this mechanism?
  • What happens if the PIN entered is incorrect?
    • How many incorrect tries do we grant per user?
    • What happens if the user takes back the card after two attempts and then reinserts the card again? Do the first two wrong tries still count?
    • If the user exceeds maximum allowed number of wrong attempts, do we take his card away or just prevent him from using the machine again?

Options for the user

Jamal’s Musings – Dangerous Words To Avoid in Project Documentation

Dangerous Words

What To Do About Them?

Examples

“Acceptable”, “adequate”, "satisfactory", "suitable"

Define acceptability and how the product and stakeholders can decide what is acceptable and what is not

 

Before: House of adequate size

After: House area shall be between 2,500 and 3,000 square feet

“Efficient”, "capable", "economical", "ecologically aware", "helpful"

Explain how efficiently the product performs operations or how easy it is to use

 

Before: Efficient engine

After: Engine with a mileage of at least 100 km per liter

“Fast”, “rapid”, "swift", "speedy"

Specify minimum, maximum and desired speed

Before: Fast car

After: A car that is capable of speed of at least 350 km/hour

“Flexible”, "agile", "easily adaptable", "variable"

What specifically should the product do in response to specific changes in the environment or business objectives

Before: Flexible payments system

Jamal’s Musings - Criteria For Good Requirements

Once all of the requirements have been gathered, it is time for the analyst to write the requirements specifications document. Let us discuss the best practices that are applicable to all types of the documentation (see Table).

Each requirement listed in the document must be necessary. While it may sound somewhat silly to question the necessity of scope components since the stakeholders asked for them specifically in the first place, industry studies show that as much as 50% of requirements can be cut from the scope of the project by asking a simple question like, “Do you really need this feature?” or, “Would a project be a ‘no go’ without this component?”

The necessity of the requirement can also be checked in the following fashion: if one can trace the requirement back to the parent business problem via the parent feature and the relationship is still logical, then the requirement is most likely indispensable.

Each requirement must be verifiable, which implies that the requirement can be tested. This criterion is strongly related to the ambiguity that will be discussed a bit later in this chapter. In general, if the requirement is not measurable, it is very unlikely that it would be verifiable. For example, requirements like:

  • “The building shall be sustainable”
  • “The system shall be efficient”
  • “The light bulb shall save energy’

are not verifiable since different people can – and most likely will have a different understanding what “sustainable”, “efficient” and “save energy” mean. On the other hand, statements like:

  • “The building shall generate 50% of the energy it needs”
  • “The system shall decrease the account opening process from 27 to 4 operations”
  • “The light bulb shall have a luminous efficacy of at least 55 lumens per watt (lm/W)

are completely verifiable because it is very easy to test whether they conform to the requirements imposed on them by the stakeholders.

 

Criteria For Good Requirements

Criteria

Explanation

Necessary