Reaping the Benefits of Good User Requirements

From User Requirements to System Design

A critical part of any software development project is the requirements gathering. If you are unclear about what is going to be delivered, how will you know when you get there? Good user requirements lead to better estimates, improved customer satisfaction, reduced cost and a shorter duration. A few questions that need to be asked before the start of any software development project are:

* Why are we building the system?
* What benefits are we expecting to get from it?
* What do we actually need it to do?

A failure to gather business requirements or assuming we know what is required can lead to a poor outcome, requirement for extra resources, increased cost and longer duration.

As Frederick Brooks put it, "The hardest single part of building a software system is deciding what to build. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later." [1]

Providing a Firm Foundation

Good requirements gathering provides a firm foundation from which to work. Customers need to know what is being developed and that it will satisfy their needs. Developers need to know what to develop and testers what to test. A quality requirements document can provide all of these things.

When creating a requirements document it is important to get everybody involved including the customer, project manager, customer account manager, developers, testers and anyone else with a stake in the project. Requirements gathering is a joint activity not solely the domain of business analysts and project managers.

A good set of requirements enables the project manager to plan and estimate the project effectively.

Running Requirements Meetings

The Requirements Gathering Meeting is the time to get all the team members, customers and stakeholders together to define the requirements for the system. Like all formal meetings, there should be an agenda. You need to cover a number of specific things at this meeting:

1. Introduction of the people at the meeting
2. The objectives of the meeting
3. The purpose of the project
4. The expected benefits
5. The customers' requirements
6. Next steps

Ideally, a business analyst should lead an open meeting where all ideas are encouraged to draw out the customer requirements. Customers are not always good at articulating their needs, so it is important to play back your understanding of their requirements to ensure clarity. Several meetings may be needed to gather all the requirements.

The requirements are written up by the business analyst in the Business Requirements Specification and are shared with the customer. The document must be clear, concise and thorough. The customer should review and agree the contents of the document. It is not advisable to ask them to physically sign it off, as this could be interpreted as a lack of trust and get the project off on the wrong-foot.

Including use cases in the Business Requirements Specification can be very useful for documenting business process and identifying different roles in the process. Customers often find the diagrams easier to understand than just plain text.

These are some of the rules for writing requirements documents:

* Requirements are written in the language of the user
* Avoid technical jargon
* Confirm what the system will not do, as well as what it will do
* Keep it clear, concise and thorough
* Include a section for non-functional requirements

Why Gather Requirements?

These are some of the reasons for gathering requirements:

* To group your thoughts and ideas in a logical way
* To group someone else's thoughts and ideas in a logical way
* To understand what a software package must do before making a selection
* To decide whether to buy or build a solution
* As a point of reference throughout the project
* To provide a basis for testing

Common Problems

These are some of the reasons given for not carrying out requirements gathering:

* No time because of tight deadlines
* Customer not available to meet and discuss requirements
* Requirements gathering seen as a waste of time by the organisation
* Assuming we know what the customer requires without asking
* No way of effectively recording requirements
* A dislike of requirements writing

Prototyping

When the customer finds it difficult to articulate their requirements, prototyping provides a low cost way to help them visualise a potential solution. Often customers are not entirely sure what they want (particularly in software development projects) and a prototype can help tease out their requirements.

A proof of concept may be required if the technology is innovative, or the project team are unfamiliar with it. A proof of concept confirms the IT department's capability to deliver the required solution.

System Design

Once you have established and agreed a clear set of requirements, the next step is to model a software solution. Using a recognised notation can be useful at this stage and help the team create a clear and unambiguous software design document.

Before building the solution, check the software design against the requirements to ensure that what you build meets the customers' needs. Revisit the requirements document regularly to ensure you are staying on-track.

"Modeling is the designing of software applications before coding." Object Management Group [2]. A popular notation for creating models of object-oriented software is the Unified Modeling Language (UML).

The Unified Modeling Language (UML)

The development of the Unified Modeling Language (UML) began in October 1994 and represents a unification of the concepts and notations of Booch, Rumbaugh and Jacobson. UML is a technology independent notation used for modeling systems using an object-oriented paradigm.

Terry Quatrani has defined the notation as, "… the standard language for specifying, visualizing, constructing and documenting all the artifacts of a software system." [3]

UML 2.0 is comprised of thirteen diagram types split into structure, behaviour and interaction.

Structure Diagrams emphasize what things must be in the system being modeled:

* Class diagram
* Component diagram
* Object diagram
* Composite structure diagram
* Deployment diagram
* Package diagram

Behaviour Diagrams emphasize what must happen in the system being modeled:

* Activity diagram
* Use Case diagram
* State Machine diagram

Interaction Diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being modeled:

* Sequence diagram
* Communication diagram (UML 2.0)
* Interaction Overview diagram (UML 2.0)
* Timing diagram (UML 2.0)

UML is accepted by the Object Management Group (OMG) as the standard for modeling object oriented programs.

As well as for software design, UML notation can be useful during the requirements gathering stage. For instance, use case diagrams will show the users what they must do, as well as what the system will do for them. They can also be used as the basis for testing the application (creation of test plans) and development of user guides.

Good models ensure technical and architectural soundness, particularly for complex systems.

Critical Success Factors

To be successful at requirements gathering and to give your software development projects an increased likelihood of success:

* Don't assume you know what the customer wants, ask
* Involve the users from the start
* Define and agree the scope of the project
* Ensure requirements are specific, realistic and measurable
* Obtain clarity if there is any doubt
* Create a clear, concise and thorough requirements document and share it with the customer
* Confirm your understanding of the requirements with the customer (play them back)
* Avoid talking technology or solutions until the requirements are fully understood
* Get the requirements agreed with the stakeholders before the project starts
* Create a prototype if necessary to confirm or refine the customers' requirements
* Use a recognised notation, such as UML, for modeling the software
* Cross check the software design against the requirements and review regularly

UML Facts

* The development of UML began in October 1994
* UML represents a unification of the concepts and notations of Booch, Rumbaugh, and Jacobson.
* UML is accepted by the Object Management Group (OMG) as the standard for modeling object oriented programs
* UML is a popular notation for creating models of object-oriented software
* The current standard is UML 2.0 a major rewrite
* UML is technology independent and can be used for any type of software development
* Specific UML development tools exist, but the diagrams can created using programs such as Visio
* UML belongs to the Object Management Group (OMG) not Rational as many people believe

Capability Maturity Model (CMM) Overview

The Software Engineering Institute (SEI) at Carnegie Melon University, sponsored by the US Department of Defence, developed the Capability Maturity Model (CMM v1.0) between 1986 and 1991. Following a workshop held in April 1992, the model was updated to v1.1 using the feedback received from about 200 software professionals.

The model is a conceptual framework based on industry best practice, used to assess the process maturity, capability and performance of software development organisations. The framework offers organisations the opportunity to identify areas for software process improvement.

The CMM framework contains five levels:

1. Initial
2. Repeatable
3. Defined
4. Managed
5. Optimising

Except for level 1, each level consists of several key process areas an organisation should focus on to improve its software process. Key process areas identify the issues that must be addressed to achieve a maturity level.

Level 1: Initial

The first level is generally considered as unplanned, occasionally chaotic, and non-process driven with success depending on individual effort.

Level 2: Repeatable

• Software configuration management
• Software quality assurance
• Software subcontract management
• Software project tracking and oversight
• Software project planning
• Requirements management

Level 3: Defined

• Peer reviews
• Inter-group coordination
• Software product engineering
• Integrated software management
• Organisation process focus
• Training program
• Organisation process definition
• Organisation process focus

Level 4: Managed

• Software quality management
• Quantitative process management

Level 5: Optimising

• Process change management
• Technology change management
• Defect prevention

An organisation that has achieved the higher levels is also assessed at the lower level criteria with stricter requirements.

Many organisations are claiming to have achieved CMM Level 4 or 5 and to be officially certified by the Software Engineering Institute (SEI). However, it is not unusual for companies to issue a press release stating that the assessment has been done at Level 5, without actually pointing out which criteria have been assessed and satisfied at that level, therefore the overall CMM assessment of the organisation may actually be nil or remain at a lower level.

As an example of good practice, the organisation should state, "Process capability has been independently assessed at a Software Engineering Institute (SEI) Capability Maturity Model (CMM) level 3. The level 5 key process area of Process Change Management has also been satisfied."

This statement describes exactly where the organisation is on the CMM staircase. It says that all the Level 2 and 3 criteria have been assessed and are satisfactory to SEI standards, as well as satisfying one level 5 criterion

Interesting CMM Facts[1]

• Average time to reach CMM level 5 with first assessment at level 2 is five to six years
• Total number of assessments from 1987 through December 2002 is 2616
• About 2000 organisations worldwide have been assessed
• Only a third of assessed organisations reached level 3 and above
• Organisation Maturity Profile (April 2003)
• - CMM 1 - 16.9%
  - CMM 2 - 43.2%
  - CMM 3 - 24.6%
  - CMM 4 - 8.0%
  - CMM 5 - 7.3%
  


• Software Quality Assurance is the least frequently satisfied level 2 process area among organisations assessed at level 1
• Integrated Software Management is the least frequently satisfied level 3 process area among organisations assessed at level 2
• On average, it takes an organisation:
• - 22 months to move from level 1 to 2
  - 21 months to move from level 2 to 3
  - 25 months to move from level 3 to 4
  - 15 months to move from level 4 to 5
  


• Higher maturity has been reached among those organisations reporting reappraisals

Some examples of CMM level five organisations are:

• NASA: Onboard Shuttle Group
• Boeing Defence & Space Group (since 1996)
• IBM Federal Systems (since 1994)

There has been a lot of interest in CMM assessments in the past 2 to 3 years. Many organisations have been assessed and received various levels of certification. About a third of recently CMM certified companies are based offshore in countries such as India.

An important point to consider is that we are not talking about only achieving a high CMM Level, but sustaining the processes at that same level over years.

ITIL: Understanding and Using IT Service Management

ITIL is a term that is fast gaining currency around the IT world. It is often wrongly described as 'IT governance' – in fact, on its own, it certainly isn't this. ITIL is a collection of best practices that helps companies implement an IT Service Management culture. However, its growing popularity reflects the substantial impact it can make on a company's IT and business performance and the fact that, in combination with other frameworks, it is a vital ingredient in creating true IT governance.

What is IT Service Management?

Today's businesses are increasingly delivered or enabled using information technology. Business and IT management need guidance and support on how to manage the IT infrastructure in order to cost-effectively improve functionality and quality. IT Service Management is a concept that deals with how to define and deliver that guidance and support. In common with other modern management practice, it views things from the customer's perspective, i.e. IT is a service that the customer or consumer receives. It can be made up of hardware, software and communications facilities, but the customer perceives it as a self-contained, coherent entity.

So what is ITIL?

Standing for 'IT Infrastructure Library', ITIL is a set of best practices that are at the heart of the IT Service Management approach. It provides guidance on how to manage IT infrastructure so as to streamline IT services in line with business expectations. ITIL is a best practice framework, presenting the consolidated experience of organisations worldwide on how best to manage IT services to meet business expectations.

ITIL was originally developed during the 1980s by the UK's Central Computer and Technology Agency (CCTA), a government body, which created ITIL version 1 as an approach to incorporating various vendor technologies and serving organisations with differing technical and business needs. CCTA has now become part of the Office of Government Commerce (OGC), which, as official publisher of the ITIL library, updated it, published version 2 and continues to develop and support it.

ITIL has since become widely adopted across the world in both public and private sectors and is recognised as best practice, being deployed in organisations of all shapes and sizes.

What makes up the ITIL Library?

ITIL documentation consists of seven 'sets' or 'volumes': Service Support, Service Delivery, ICT Infrastructure Management, Security Management, Planning to Implement Service Management, The Business Perspective and Applications Management.

Of these, Service Support, Service Delivery and Security Management are considered the central components of the ITIL framework, covering vital issues such as Incident Management, Configuration Management, Change Management, IT Service Continuity Management, Availability Management and IT Security Management.

Learning about ITIL

The seven ITIL volumes are published by The Stationery Office, the official publisher of the UK government, and are available from http://www.itgovernance.co.uk/catalog/23 . In addition, to gain an overview and a sense of how to navigate these, it is helpful to consult one of several recommended introductory texts. 'Foundations of IT Service Management Based on ITIL – An Introduction' is widely accepted as the best starting point and self-study guide. 'Implementing Service and Support Management Processes – A Practical Guide' is a thorough and comprehensive handbook on the subject, while the 'itSMF Pocket Guides' provide a good overview of each of the ITIL components. These supporting texts may be obtained at http://www.itgovernance.co.uk/catalog/7

Getting certified

Part of the reason for the recent growth in ITIL awareness is the publication in December 2005 of a new global standard to which businesses can become certified. ISO 20000 (or ISO/IEC 20000:2005, to give it its correct name) is closely based upon the pre-existing British standard BS15000 – in fact, it is virtually indistinguishable. The standard comprises two parts: ISO/IEC 20000-1 is the specification for IT Service Management against which an organisation's practices can be certified; ISO/IEC 20000-2 is the 'code of practice' that describes best practices and the requirements of Part 1.

BS15000 has become widely used around the world since it was published in 2003 and was adopted virtually unchanged as the national standard in Australia and South Africa. A number of companies across the USA, Europe and Asia have already become certified as BS 15000 compliant. We also recommend several excellent books that provide guidance on achieving BS15000/ISO 20000 compliance.

Upon the publication of ISO 20000, BS15000 was withdrawn and individual standards and certification bodies are drawing up their own formal transition programmes for conversion to the new standard. Companies already holding BS15000 should encounter no difficulty in converting their certification to the new standard, as this should be one of the considerations addressed by the individual certifying bodies.

Practitioners can also pursue a structured programme of ITIL examination and certification, comprising the ITIL Foundation Certificate, ITIL Practitioners Certificate and ITIL Managers Certificate. Examinations and certification in Europe are managed through two independent bodies: EXIN, the European Examination Institute for Information Science; and ISEB, the Information Systems Examination Board. Between them, these two organisations control the entire certification scheme. In the United States, HDI is a principal organiser of examination and certification, and it and similar organisations provide coverage elsewhere around the world. These organisations ensure that personal certification is fair, honest and independent of the organisations that provide the training, and accredit training suppliers to bring about a consistent quality of course delivery.

ITIL and IT Governance

When combined with certain other frameworks, ITIL makes a major contribution to the creation of effective IT governance. ITIL processes can be mapped to CobiT (Control Objectives for Information and Related Technology) processes, and the two frameworks complement each other nicely: if the CobiT control framework tells the organisation 'what' to do in the delivery and support areas, ITIL best practices help the organisation define 'how' to deliver these requirements. Similarly, ITIL works very effectively with ISO 17799, the international code of best practice for information security, providing guidance on how to manage the various processes that ISO 17799 prescribes.

By drawing upon these three complementary frameworks as appropriate to its needs, an organisation can establish an IT governance regime that delivers real and lasting competitive advantage to its business.

Successful Software Development - It's Not Rocket Science

Sometimes I wonder after years of software development whether things have really changed that much. Sure, technology has moved on at pace, but has our approach to running software development projects.

Users remain baffled by techno speak, developers prefer to invent rather than reuse and know what is best for you before you tell them what you want, while projects frequently miss deadlines and exceed budgets.

Just look at the Ministry of Defence who wasted nearly £30m on two IT projects alone. The first project, a communications system for the RAF, was abandoned because of problems integrating it with other systems and £21m was written off. The second, a pay system for the Navy, was closed when it became clear that the project would cost three times the expected amount of £18.9m. £8.7m had already been spent, this too was written off. [1]

Avoiding the common pitfalls of software development is not rocket science; it's simply a case of taking some sensible measures. Identified here are five killer mistakes of software development:

Getting the Requirements

The Mistake

One of the cardinal sins in software development is rushing into a project in a peak of enthusiasm without taking enough time to understand what the customer really wants. This is one of the most common mistakes and is responsible for more failed software development projects and unnecessary rework than anything else.

The Solution

Get the customer requirements first and then fit the requirements to a solution, not a solution to the requirements. Avoid the "we know what you need" syndrome that still exists amongst some developers.

It's a good idea to use a business analyst to gather the requirements as they tend to take a non-technical, objective view of what the customer wants.

It's all to easy to get railroaded into 'coding' before the requirements are fully understood, but time spent up front with the customer will prevent a lot of pain and rework later.

Understanding the Lingo

The Mistake

Have you ever stood next to a group of software developers and wondered what they were talking about. It's like a completely new language and to non-IT people it often is. The pitfall comes when the customer and IT think they are talking the same language when in fact they are not. This leads to a problem when the IT department delivers what they understood the customer wanted and it turns out to be something different.

The Solution

Communication problems are the hardest to resolve, as often it is only looking back that the problem is identified. Regular communication and a close working relationship with the customer will help. What you really need is a person with a foot in both camps. Someone who understands the business and the IT equally well. If you can identify this person make sure you keep hold of them, they are hugely valuable. If you are unable to find this person, the next best option is to have two people, one from the business and one from IT. By working closely together and sharing information, they can minimise any communication problems.

Managing Expectations

The Mistake

Often there is an expectation that IT is like a magic wand you wave and suddenly a miracle occurs. During a software project, expectations can inflate to a ridiculous degree. It is the role of the project manager to manage expectations to a sensible level.

The Solution

One way to avoid this is to break a project into smaller pieces or phases. I equate this to a sausage machine, where you feed in the raw material at one end and out it comes as small, perfectly formed, packages or sausages at the other end. The same can happen with software projects where you take small packages of requirements and push them through the machine, producing several deliverables over the life of a project. This way you manage expectations by making frequent deliveries to demonstrate what the technology can really deliver. This approach ensures the project delivers to the customers' expectations by giving them early visibility of what you are building.

Prototyping

The Mistake

Customers often find it hard to articulate their requirements, with many people only able to say what they want when they see it. Building a system when you are not totally clear what the requirements are is a serious mistake. If the developer has not understood the requirements, it is likely that this will not show up until very late in the development lifecycle.

The Solution

When there is a lack of clarity about the requirements, an effective technique is prototyping. A non-functional prototype can be produced quickly and cheaply to help you draw out detailed requirements from the customer. This way the developer tests his understanding of the requirements and avoids waste and rework later.

Testing Comes First

The Mistake

If the customer tests the software and finds a lot of bugs, however minor, you will lose their confidence. It is always harder to get customer confidence back once they have had a bad experience. It is easier and more cost effective to test the software thoroughly for bugs before giving it to the customer.

The Solution

Use professional testers to test the software; they tend to look at it from an end users point of view. Never ask the person who developed the software to do the testing, they will not be objective and already know how the software is intended to work. You need someone that comes to it fresh and asks, is this logical, is it intuitive, does it work and does it meet the customer requirements.

You can demonstrate the software to the customer before it is tested, but do not let them have access without being in control yourself.

Finally

Research in April 2003 for Unilog, the independent pan-European IT consultancy and services company, found that 100 per cent of IT managers had experience of a project that had failed to meet all of its objectives. Three of the reasons given for these failures were:

1. Lack of proper ties between IT and the business
2. Expectations not properly set
3. Inadequate project scoping

Concentrating on these three aspects alone will give you a good chance of success.

Don't become the victim of a failed software project, put measures in place that will ensure your success. After all, it's not rocket science!

What is ITIL?

Definition

ITIL stands for Information Technology Infrastructure Library. It provides a comprehensive, consistent and coherent set of best practices focused on the management of IT service processes.

ITIL promotes a quality approach to achieving business effectiveness and efficiency in the use of information systems.

History

Since the mid 1990's ITIL has been promoted as a standard for IT Service Management. ITIL is built on a process-model view of controlling and managing operations.

The recommendations of ITIL were developed in the late 1980's by the Central Computer and Telecommunications Agency (CCTA), which merged into the OGC in April 2001 and disappeared as a distinct organisation. The CCTA created ITIL in response to the growing dependence on information technology to meet business needs and goals.

In December 2005 the OGC issued notice of an ITIL refresh, commonly known as ITIL v3, to be completed initially by April 2006.

Overview of the ITIL Frameworks

ITIL is defined by a collection of books that describe guidelines for different aspects of best-practice data centre management. Taken as a whole, ITIL presents a comprehensive view of the field. The subjects of the individual books are referred to as sets; currently there are eight. The sets are further divided into disciplines, each of which is focused on a specific subject.

The eight sets and their disciplines are:

1. Service Delivery. What services must the data center provide to the business to adequately support it.

1. IT Financial Management
2. Capacity Management
3. Availability Management
4. IT Continuity Management
5. Service Level Management

2. Service Support. How does the data center ensure that the customer has access to the appropriate services?

1. Change Management
2. Release Management
3. Problem Management
4. Incident Management
5. Configuration Management
6. Service Desk

3. Planning to Implement Service Management. How to start the changeover to ITIL. It explains the necessary steps to identify how an organisation might expect to benefit from ITIL and how to set about reaping those benefits.

4. Security Management.

5. ICT Infrastructure Management. What processes, organisation, and tools are needed to provide a stable IT and communications infrastructure. This is the foundation for ITIL service management processes.

1. Network Service Management
2. Operations Management
3. Management of Local Processors
4. Computer Installation and Acceptance
5. Systems Management

6. The Business Perspective. It explains the key principles and requirements of the business organisation and operation and how these relate to the development, delivery and support of IT services.

7. Application Management. How to manage the software development lifecycle, expanding the issues touched upon in Software development lifecycle and testing of IT services.

8. Software Asset Management.

Using ITIL

From the beginning, the ITIL Framework has been publicly available, however, it is copyright protected. This means that any organisation can use the framework described by the OGC in its numerous books. Because of this, ITIL guidance has been used by a wide range of organisations including local and central government, energy, public utilities, retail, finance and manufacturing. Very large organisations, very small organisations and everything in between have implemented the ITIL processes.

How is Software Development guided?

The software development process is almost invariably guided by some systematic software development method (SDM). Referred to by a number of terms, including process models, development guidelines, and systems development life cycle models (SDLC), software development methods nevertheless generally include the same development phases:

The existing system is evaluated and its deficiencies identified, usually through interviewing system users and support personnel.

The new system requirements are defined. In particular, the deficiencies in the existing system must be addressed with specific proposals for improvement.
The proposed system is designed. Plans are laid out concerning the physical construction, hardware, operating systems, programming, communications, and security issues.

The new system is developed. The new components and programs must be obtained and installed. Users of the system must be trained in its use, and all aspects of performance must be tested. If necessary, adjustments must be made at this stage.

The system is put into use. This can be done in various ways. The new system can phased in, according to application or location, and the old system gradually replaced. In some cases, it may be more cost-effective to shut down the old system and implement the new system all at once.

Once the new system is up and running for awhile, it should be exhaustively evaluated. Maintenance must be kept up rigorously at all times. Users of the system should be kept up-to-date concerning the latest modifications and procedures.

How has the open source development process influenced software development in general?

Open source development software is developed collaboratively; source code is freely available for use and modification. The open source movement arose because some developers came to believe that competition amongst vendors’ leads to inferior products and that the best approach to development is a collaborative one.

The OSI (Open Source Initiative) is an industry body that certifies products as open source if they conform to a number of rules:

The software being distributed must be redistributed to anyone else without any restriction
The source code must be made available (so that the receiving party will be able to improve or modify it)
The license can require improved versions of the software to carry a different name or version from the original software

Despite its emphasis on the collaborative process, the biggest influence that open source has had on software development in general may be through competition: by competing with proprietary software products, open source products force vendors to work that much harder to hold their market share in the face of viable open source alternatives.