Date: February 19, 2004
Printer Friendly Version
Analyzing Requirements and Defining Microsoft.NET Solution Architectures, Part II...
Gathering and analysing requirements (business).
Date: February 19, 2004
Printer Friendly Version
The aim of this series of articles is to provide an overview of issues surrounding the architecture of .NET Solutions. In doing so we are loosely following Microsoft's recommended approach and, in particular, looking at the requirements of the related Microsoft certification exam (70-300), which itself is one of the requirements for the MCSD .NET qualification. The main reference for this series of articles is the Que publication: 'Exam Cram2 .NET Solution Architectures'.
In article I we looked at phase one of the process of Analysing Requirements and Defining Microsoft .NET Solution Architectures, the Envisioning Phase, the output from which was a high level definition of the planned solution and issues it is focussed on addressing. Next we start on gathering and analysing the requirements that will flesh out the high level definition of requirements with further detail. We'll start in this article with business requirements.
As you read the following you may think we're diverting too far from computing issues into business issues. We're not. Understanding and consideration of the involved business issues is key to a successful project. It is up to you to determine the scope of the consideration. Further, you can put in place the finest new computer system but if the surrounding business processes, organisational structure, etc. are lousy the positive impact of the new system may be minimised.
The business requirements describe the business purposes for developing a new computer system or enhancing an existing one. The process commences by gaining a thorough understanding of the current applicable business state. This details how the pertinent key functions of the organisation, including existing computer applications, are attempting to achieve the organisation’s business goals. You use the current business state as a starting point to determine what needs to change to get to the desired business state. By using the existing system you can identify and document problems and their causes and thus identify opportunities for system improvement.
To evaluate the current business state you focus on the following areas, discussed briefly.
A business process is a set of work activities designed to produce a specific output for a particular customer or market. The output of a business process is a product or service. Business process analysis enables increased understanding of the way a business unit fulfils its mission. A business unit is the collection of all functions needed to bring a product line to market. Once analyzed you can assess the effectiveness of the business processes and decide which should be replicated in the new system and which should be amended (business process reengineering).
Organisational structures define the roles and activities required of people so that business objectives can be met. For an organisation to be successful, its organisational structure must be aligned with its strategic vision. There are four main objectives for an effective organisational structure:
An effective organisational structure must be in place so that the organisation can achieve its goals and objectives. Organisational structure is important when an organisation changes its strategic direction to help management implement the required process changes.
Assessing the current organisational structure as part of the systems development lifecycle is sensible as the need for a new computer system is likely to be triggered by changes in the company itself and thus the success of the computer system and the company could depend on parallel changes in the organisational structure.
An organisational structure commonly falls into one of the following types or a combination thereof:
Functional – organised around skills; most effective in single business firms in which key activities revolve around a well defined set of processes.
Matrix – two or more chains of command with a complex network of reporting relationships, the idea being that this allows the company to be flexible and respond quickly to change.
Geographic – organised specifically for the market being supported. Best for organisations pursuing different strategies in different geographical markets.
De-centralised business units – each business unit operates as a standalone profit centre. Works well for diversified organisations allowing strategic decisions closer to the knowledge of the business unit.
Strategic business units - addresses overall strategic issues immediately; works well for highly diversified organisations that still want to enforce strategic coordination across related businesses yet have more cohesiveness across units than the decentralised business structure offers.
It is important to consider that you should expect resistance to organisational change at all levels of the organisation. However, an allied consideration is that organisational change may be key to the success of your project.
The requirements gathering team should be aware of where the organisation fits in terms of industry position. The current and desired industry positions could be key to justifying the development project. For example the software solution could have the aim of enabling the provision of a superior product at a reduced cost with the aim of increasing market share and overtaking competitors.
The industry's lifecycle phase should also be considered – whether the industry is in a declining or growing phase may effect the importance of systems development and the requirements thereof, e.g. timescales so as to allow exploitation of opportunities before they disappear.
A vertical market is a collection of common businesses that a company manages. An organisation might have identified other vertical markets it wants to expand to, and implementing a new business system will improve its efforts. Broad examples of vertical markets are: insurance, real estate, banking, heavy manufacturing, retail, transportation, hospitals, and government. Vertical market software is software aimed at a particular vertical market and can be contrasted with horizontal market software (such as word processors and spreadsheets) that can be used in a cross-section of industries.
What additional employee skills are needed to make this new project a success? Is additional training sufficient or will additional resources be required?
You won't be surprised to learn that company politics is frequently a significant factor, particularly when the project means significant change to involved parties. People will often out their own self-interests ahead of the organisations well being.
Some companies operate in highly regulated industries and in such case the regulatory requirements will have to be represented in the requirements.
With analysis of the current business state completed it is now time to determine the business requirements of the solution. Ask the following questions:
To successfully answer these questions you should focus on the following areas:
These areas we'll now consider in turn:
High level expressions of desired system behaviours are called system features, which can be defined as services a system provides to fulfil one or more of a user's needs. They can be a good way to define system functionality without getting too detailed.
Features can be thought of as a buffer between what users need and how you will eventually translate those needs/ features into business requirements. Discussing how the user's true need will be addressed by implementing a feature is essential as features may be quite vague. Features also provide a good way to review and prioritise requirements in a way users can understand as well as being a good way to communicate the projects purpose to upper management. They basically provide a high level summary of more detailed requirements.
Firstly you need to identify information sources and start gathering requirements. Key sources are likely to be:
When capturing requirements you need to judge whether the stated desired application functionality is truly relevant to current and future business needs. Managing users expectations should also begin at this point ... irrelevant ideas can be politely dismissed ... but make sure you are sufficiently informed to correctly classify them as irrelevant.
Secondly comes classification and prioritisation of the captured requirements. The classification exercise should prioritise the requirements into functional, performance, constraining, informational and subjective requirements. You should resolve conflicting requirements. You should obtain stakeholders agreement on the consolidated set of requirements.
Thirdly comes creation of a vision/ scope document – a more detailed and business based version of the same titled activity from the envisioning phase. The resultant document:
An internal dependency is any relationship between two or more activities that could affect scheduling these activities, e.g. you can't test the application until the new testing platform is installed and configured. Most internal dependencies are a direct result of resource availability. Having alternative resources available, perhaps through training, can eliminate many internal dependencies.
An external dependency is an activity or event outside the direct control of the project but has a direct effect on the project, e.g. development of a software component needs to be completed before your project commences. External dependencies are normally activity driven rather than resource driven and are more difficult to mitigate against. You can try to do so by putting contingency plans in place, or reworking the project to eliminate the dependency entirely.
There are likely to be plenty of dependencies in the project so focus on the more important ones.
What business data is required to meet objectives? Determine this via data modelling – identify the kinds of data needed by your application and document the business relationships among the data. This involves reviewing existing data models and processes for reuse if available, and creating new data models and processes that meet the new applications requirements. Key sub-steps are:
When it comes to modelling data there are 5 main areas on which to focus:
Note that this is data modelling to describe data and business relationships ... it is independent of any implementation approach, technology, hardware or software though the architect will find it difficult not to think in terms of SQLServer standard datatypes, for example!
These allow diagrammatic and logical representation of the system. The idea is that diagrams are easier to understand than reams of text and thus will aid a common understanding of the proposed system between users, developers and other stakeholders. You may choose to model the current system as a starting point as these may well help understand the future requirements better as well.
An important output is the definition of system boundaries/ project scope.
DFDs use four symbols:
 | External entities: sources or destinations of data to/ from the system |
 | Data flows |
 | Data stores |
 | Processes |
Key to creating DFDs is hierarchical organisation. The top-level overview diagram is the context diagram that shows system boundaries, external entities that interact with the system and major information flows between the external entities and the system. The level-0 diagram shows a system’s major processes, data flows and data stores at a high level of detail, with each process being assigned a number which is used to mark the hierarchy at lower levels. The level-n diagram takes one of the processes from level-0 and breaks it down further. The lowest level is called a primitive level DFD.
The DFD drawing process is:
After the primitive DFD level is reached you can use other modelling tools such as structured English, decision tables and trees to describe the actual logic needed to complete the individual processes.
The process of gathering and analysing business requirements consists of two specific phases:
The first informs the second, particularly via gap analysis. The second follows the following:
I've only had space here to provide an overview of some of the recommended concepts and processes, a consideration of which have the potential to lead to a complete and accurate specification of business requirements of your new system. You should follow up this introduction with both some practical application of the ideas presented and some further reading, and the Microsoft Architecture site (see references) would be a good place to start.
Part III of this series will focus on gathering and analysing user requirements.
Exam Cram 2 .NET Solution Architectures
Cornish et al.
Que
http://msdn.microsoft.com/architecture/