Difficulties Of Uncovering Requirements

Published Date: 02 Nov 2017

Introduction

Business Analyst has always worked hand in hand with system analysts. They stand in the front line, communicating with customers and owners on their business needs and system requirements while system analyst support by doing the coding and delivering the system. Therefore, communication between BA and customers is crucial in order to start off the project on the right foot. This essay aims to show users what contributes to a project failure and how to avoid it. We will discuss ways to use UML class diagrams to uncover business requirements more effectively. Class diagram often enhance the requirements definition process, improve communication of requirements, and simplify the transition from requirements to design. It proposes a translation method between the language used by business analysts when designing a business model and the one easily understood by the developers when implementing a process. (Podeswa, The Business Analyst’s Handbook 2009)

Background

According to reports, most project failures occur because of the failure to determine the correct business requirement or the scope of requirements is too large or not precisely stated during the initial phase. The mismatch between what the user wants and what the developers deliver can often be traced to poor practices in business analysis and quality control. In addition, many IT projects are experiencing time and cost overruns due to the difficulty in responding to a rapidly changing business environment.

Why software projects fail and the various problems faced

Wasting time

Companies waste precious time in meeting to discuss and clarify the same questions and issues over and over before everyone finally understands. Millions of dollars are wasted as they are carrying out unproductive rework because they didn't explore the business requirements sufficiently to build a strong foundation before going into the implementation phase.

Did not follow standards

Although company spend money defining good requirements practices and getting standard templates and procedures for the analysts to use, people are reluctant to follow as they feel that these procedures are too troublesome to use. They prefer to do it the fast and easy way.

Difficulties of uncovering requirements

Initial phases of gathering requirements are challenging as customers usually are not clear of what they want or need in the end product. They only have vague ideas and find difficulty converting their tacit ideas into words. Because of this, people usually fall back on using the old ineffective methods of interviews and unproductive meetings to review textual requirements.

Ripple effect and ever-changing requirements

One change in the business model that leads to many changes in project deliverables. In the course of implementing the project, it is very common for initial requirements to be overshadowed by more crucial ones which are discovered later.

Gap between Business and IT

As both groups are from different backgrounds, they speak different languages. IT people tend to be more practical and technical while business people tend to overlook the technical aspect and just focus on the deliverables documents and profits. Because of the miscommunication, projects may take too long to start and misunderstandings may occur.

IT people speak their geek language and expect us to know about IT stuff when we're telling them what we want. They sometimes show us funny diagrams and expect us to approve them. Or they write long boring sentences that are supposedly formalizing our requirements and these are hard to follow. Or they shove these other documents (e.g. use cases) at us, and we're expected to just sign off and expecting us to agree that the content of the documents are what we need them to do.. (EBG Consulting n.d.)

Scope creep 

It is not unusual for market and business conditions to change during the course of building the system which in turn will cause the requirements to change too. According to survey, scope creep is a major factor in project cancellations and one of the most common source of cost and schedule overruns (Capers 2000). Frequent changes, missing requirements, insufficient user communication, poor specifications, and insufficient analysis—account for the five top causes of poor software cost estimation (Ann M. Hickey 2003).The development team can spend as much as 30 to 80 per cent of their project effort reworking mistakes they made earlier.

Roles of a Business Analyst

The business analyst is the vital link between business and IT executives, translating business goals into IT requirements. Usually systems that fail to meet expectations usually derived from a vaguely defined business expectation. By improving communication between business stakeholders and developers in IT, the business analyst reduces costs and delays.

Define project scope

The starting point for any business analyst is to define a project’s purpose and goals. The business analyst must first document a project’s scope, identifying all people or departments involved and any external and system resources needed.

Define requirements

The analyst typically uses many different techniques to gather information, including a review of existing documentation, interviews, online research, surveys, questionnaires and personal observations. The business analyst must have advanced interviewing skills, including the ability to dig deep with follow-up questions, interview people with different points of view and draw conclusions.

Document requirements

The business analyst must firstly have a considerably amount of background technical knowledge so as to serve as a bridge to transition business requirements into technical aspects. The analyst typically uses Unified Modelling Language (UML) — the current industry object-orientation standard to prepare requirements and diagrams.

Identify solutions

The business analyst must thoroughly understand business objectives and software functionality to ensure that the identified solution is fully aligned with the needs of the business. He should also be able to weigh return profits against production cost and build support for implementation.

Continued support

Even after the completed system is handed over to the customer, the business analyst remains involved as most commonly bugs will surface after handover. In addition, the user requirements might change therefore they must adjust the design accordingly and review designs using use-case scenario to ensure that they will satisfy requirements. (Orosz n.d.)

Using UML class diagrams to uncover requirements

UML Class Diagrams can be used to document both software design and requirements. It reflects the cardinality and relationship between classes. Diagrams are easier to understand than text documents. It allows for clarity of communication, by creating descriptive and unambiguous documentation of requirements.

The Class

The class represents a concept, entity, item, or object. It is important for analysts to model it after how the business thinks about these objects and not how developers will implement a representation of the objects. Each class has a name of its own. The middle section represents attributes, and the lower section captures operations that can be performed by it. If an attribute has other attributes, it should be a class. (Sehlhorst 2008)

Relationships

Relationships are defined by the arrow symbol between the class and a small description above it. It must be accompanied by cardinality with respect to the tables.

Forms of multiplicity: (Pender 2003)

Class A

Class B

Relationship Explanation

example

1

1

Only one instance of Class A can have one instance of Class B

person <-> IC

0..1

1

Zero or one instance of Class A can have only one instance of Class B

date of birth <-> person

* 

*

Multiple instance of Class A can have multiple instance of Class B

person <-> book

1

1..*

One instance of Class A must have at least one instance of Class B

person <-> language

The customer receives bills at an address. That is the relationship between the customer and the address. Therefore from the above example we can deduce that:

A customer has a credit rating as one of its class properties.

An address includes fields for street information, city, state/province/county, zip or postal code, and country fields.

A customer receives bills at exactly one address.

Many customers can receive bills at any one address.

The diagram above shows the example for many to many relationships. A nonspecific relationship (or many-to-many relationship) is one in which many instances of one entity are associated with many instances of another entity.

Nonspecific relationships must be resolved as current relational DBMS do not support this type of implementation. Most nonspecific relationships can be resolved by introducing an associative entity. This is an entity that inherits its primary key from more than one other entity. Each part of that concatenated key points to one and only one instance of each of the connecting entities.

The multiplicity and relationship description show how pairs of entities interact or inter-relate. The relationships directional and bidirectional depending on the way business needs to look at things.

Combination of relationship into one

Shaded diamond symbol is use to indicate the composition relationship while unshaded diamond is used for aggregation.

Composition – when one item is part of another item, the relationship is composition therefore if the composite is destroyed; it must destroy all its parts.

Example:

A building is composed of one or more floors (a floor is part of a building)

A plane is composed of motor, one or more engines, and one or more wings (a wing is part of a plane)

A car is composed of one engine (engine is part of a car)

Aggregation – when one item can be included in another item, the relationship is aggregation; it is used to represent ownership or a whole/part relationship

Example:

A team includes more than one players

A school includes more than one student

A hospital includes more than patient

You could expel a student and the school still exist likewise, you could kick one of the players off a team and the team would still exist.

Generalization

Generalization is another type of relationship that helps us better describe objects. It means whatever the parent has the child will inherit the same things. All properties that are true about the parent object are true about the child object. However it is not the same the other way round. In the example above, workers can be divided into full time or part time.

Relationships, Classes, and Inheritance

You can uncover more hidden requirements and depicts a clearer picture for everybody when you combine these different analyses within a diagram. For example the diagram we looked at above provides a good description of how the system is expected to handle the daily operations; from enrolling a new student to taking attendance. As everybody get to the same level of understanding, the project will be prone to lesser misunderstandings.

(Podeswa, UML for the IT Business Analyst: A Practical Guide to Object-Oriented Requirements Gathering 2005)

Steps to avoid scope creep

There are a number of strategies you can follow to keep scope creep from derailing your projects. Every development effort should have a corresponding project plan or project agreement before you even begin them. Use the following guidelines to avoid scope creep from happening. (Doll 2001)

You need to understand the project vision very clearly. Meet with the project drivers and deliver an overview of the project and take note of any feedbacks.

Make a list of things that must be done and arrange them according to their priority. It should also include budget, deadline, feature delivery, customer satisfaction, and employee satisfaction. You’ll use this list to justify your scheduling decisions once the project has commenced.

Define your deliverables and the project drivers agree and sign off. This is to make sure that we have some documentation to fall back on in case of any disagreement later.

Break the approved deliverables into actual work requirements using a spread sheet. The requirements should be detailed and always include time for ample documentation.

Break the project down into major and minor milestones and get it approved by the project drivers. Leave room for error when planning the schedule. If your schedule is tight, re-evaluate your deliverables. Coming in under budget and ahead of schedule leaves room for additional enhancements.

Once a schedule has been created, assign resources and determine your critical path using a PERT Chart. Using this chart you have an overview of which deliverables must be completed on time and which have room for allowance.

Expect that there will be scope creep. Implement Change Order forms early and educate the project drivers on your processes. (Melik 2007)

With all these in place you will be in a better position to control your project, instead of your project controlling you.

Conclusion

Determining the business requirements must be done in the correct manner and it should not take too long just to start off the project. Once everybody agrees and understand on the business expectations that the system should deliver, the team will then be able to work towards a common goal without any disagreement. People should be focusing more of their time and giving constructive discussions on how to develop quality end product instead of arguing on what should be included in the scope or disagreeing with the budget and timeline. However we should not overlook the planning and requirements phase as it is a very important step to start off. Failure to do the initial phase properly may cause the entire project to cripple in later stages.