Week 2

Requirements Elicitation and Analysis

Overview

As we enter the third millennium, organizations have to cope with accelerating rates of change in technology and increased levels of competition on a global scale more than ever before. There is incredible pressure on companies to achieve and sustain competitive advantage.

In order to stay competitive within this changing business environment, organizations are forced to constantly pursue new strategies to differentiate themselves from their competition, such as offering a stream of new products and services.

Organizations in search of competitive advantage become more conscious of how software products have become a strategic asset to their business.

Overview

Software companies, like many other organizations, are forced to adapt to the strategic challenges and opportunities presented by the new economy where new technology causes dramatic changes in business processes, products and services.

Since software products play a vital role in supporting strategic challenges and opportunities in business, it is important that these products function according to customers’ or markets’ requirements.

Hence, an important task in software development is the identification and understanding of key business requirements to ensure that software products will fully support and evolve with the system.

Overview

Requirements Engineering (RE) is the process by which the requirements for software products are gathered, analyzed, documented, and managed throughout the SE lifecycle.

RE is concerned with interpreting and understanding stakeholders’ goals, needs and beliefs.

Overview

There are many problems associated with RE which may lead to inconsistent and incomplete requirements and cancellation of software projects.

As RE is one of the main contributors to the success of software projects, improving the RE process can significantly increase the likelihood of software project success.

Software developers realize that a strong requirements management process is essential to the successful completion of software projects.

Overview

Furthermore, understanding, identifying and articulating the role of business requirements which are elicited from stakeholders from diverse backgrounds with different needs, expectations and goals is a challenge in RE.

Quality management in software development starts with an accurate description of business processes and a basic understanding of stakeholder needs.

Requirements analysis is a critical task in software development as it involves investigating and learning about the problem domain in order to develop a better understanding of stakeholders’ actual goals, needs, and expectations.

Overview

This course looks at software requirements from both engineering and management perspectives.

It is an engineering activity because it is concerned with identifying appropriate methodologies to develop software solutions and identifying cost effective ways of doing so. In other words, the aim of RE is to introduce engineering principles into the practice of software systems analysis while integrating RE with a quality assurance process of utmost value to practitioners.

Overview

Requirements change during the software development lifecycle and evolve after the system has become operational.

Thus, RE is also a “management” activity as it is concerned with managing RE activities such as monitoring product requirements and managing the project scope, cost and schedule throughout the software development process, while ensuring that all essential business applications are delivered as specified in different requirements documents on different levels, for example, product and project levels.

Requirements Engineering

RE is accepted as one of the most crucial stages in software design and development as it addresses the critical problem of designing the right software for the customer.

It is becoming a set of processes that operates on different levels – organizational, product and project levels

The importance role of RE

The development of a software requirements specification is widely recognized as the bases of system functionality.

Software requirements are the critical determinants of software quality.

Standish group report in 1995 57.2% of project costs 189% of their original budget

estimates 42% of the original features are implemented 16.1% of all US software projects are developed on-

schedule, on-budget ad with all originally planned features 31.1% of projects are terminated before completion. It is also observed that the average project is delivered at

approximately three times the budget and in three times the scheduled time.

What is the causes of these deficiencies? According to a survey conducted with 350

organizations in the USA 9with over 8000 projects), one third of the projects were never completed and one-half succeeded only partially.

About half of the manager interviewed identified poor requirements as a major source of problems, along with other factors such as low user involvement and unclear objectives.

Similarly, according to another survey which was conducted with 3800 organizations from over 17 countries in Europe, most problems are in the area of requirements specifications (50%) and requirements management (50%).

In 1999 Standish group report revealed that three of the top ten reasons for ‘challenged’ projects and project failure were lack f user involvement, unstable requirements and poor project management.

In 2001, while user involvement was no longer a key concern, unstable requirements and poor project management remained amongst the primary reasons for project failure.

In more recent survey of 12 UK companies’ requirements problems accounted for 48% of all software problems.

In one of the case studies, Tveito and Hasvold observed that there was a huge gap between the day to day operations of a hospital and software developers’ domain knowledge of these operations, though every year healthcare organizations spend large amounts of money and resources on IT systems.

This gap is due to insufficient requirements gathering and misunderstanding requirements due to the lack of human knowledge.

Furthermore, the cost of repairing requirements-related problems dramatically increases as the software development process progresses.

A study by Boehm and Papaccio, it costs US$1 to locate and fix an error in the requirements definition

stage, US$5 in the design phase, US$10 in the coding phase US$20 during the unit testing Up to US$200 after system delivery

RE process has important ramifications for the overall success of a software project.

Although the above example dates back just over 15 years, the ratio remains the same today.

RE is concerned with the identification of goals for a proposed system, the operation and conversion of these goals into services and constraints, as well as the assignment of responsibilities for the resulting requirements to agents such as humans, devices and software.

RE has now moved from being the first phase in the software development lifecycle to a key activity that spans across the entire software development in many organizations Waterfall….agile approach

Researchers agree that the RE process should consist of structured and repeatable activities where both engineering and management aspects are properly handled.

Unfortunately, there is no consensus regarding the appropriate RE process models to use across different industries as the selection of available ,models span from activity-based process models to decision-oriented paradigm.

What is requirements?

Requirements are description of how a software product should perform.

A requirements typically refers to some aspect of a new or enhanced product or service.

The widely cited IEEE 610.12-1990 standard defines a requirements as A condition or capability needed by a user to solve a

problem or achieve an objective. A condition or capability that must be et o possessed by a

system or system component to satisfy a contract, standard, specification or other formally imposed documents

Ideally, requirements are independent of design, showing ‘what’ the system should do, rather than ‘how’ it should be done.

In practice, however, this is not always possible.

Requirements can be classified in many ways.

Functional req What the system will do

Non-functional req Constraints on the types of solutions that will meet the FR eg accuracy, performance

Goal level req Related to business goal

Domain level req Related to problem area

Product level req Related to product

Design level req What to build

Primary req Elicited from stakeholders

Derived req Derived from primary req

Business req vs technical req

Product req vs process req Business needs vs how people will interact with the system

Role based req e.G customer req, user req, IT req, system req and security req