Process Five: Define What Is Required of a New System
Process Five: Define What Is Required of a New System The "requirements" of requirements analysis are the specification of what is to be done with a new system. This does not mean that a new system itself is to be described in detail. Rather, what is produced is a statement that includes:
Step 1: Restate Project PurposeIn the beginning, there was a reason why this requirements analysis project was initiated. There was a perceived need for information or processing that was clearly not being met by current systems. The pharmaceutical company wanted to shorten the time required to gain FDA acceptance of a new drug. The oil refinery wanted to improve control over its processes. The cable television network wanted to have more control over where commercials were placed, and, similarly, to provide more control to its sponsors. In all cases, there is an overriding business need, expressed in the strategy report, that created the project in the first place. Write that down, and publish it as the frontispiece to all other project documents. Step 2: Identify Key PlayersThe ultimate success of any project will be its acceptance by the people who will depend on it for their jobs. These people are the ultimate source of all requirements definitions. Suzanne and James Robertson, in their 1999 book, Mastering the Requirements Process , describe these key players as:
Step 3: Identify Required CapabilitiesThe Robertsons describe functional requirements as "the things the product [new system] must doan action that the product must take if it is to provide useful functionality for its user. Functional requirements arise from the fundamental reason for the product's existence" [Robertson & Robertson, 1999, p. 104]. In addition, non-functional requirements are "properties, or qualities, that the product must have. In some cases the non-functional requirements are critical to the product's success" [Robertson & Robertson, 1999, p. 112]. To arrive at these required capabilities, then, it is necessary not to ask the users what they want, but to look at the models, examining the difference between the business owners ' views of their current systems and the architect's view. What data that are in the enterprise model are missing from the current world? What processes could be rendered more rational? Task 1: Identify Missing DataA conceptual data model will describe all (or nearly all) the things of interest to an organization. It is a theoretical artifact, in that it was created without concern for what data may actually exist. At this stage of the project, however, you have to address that question. For each entity type, does that information exist? How easy is it to get at? How easy is it to present it in conjunction with other information that is required? Categories of information that either do not exist or are inaccessible to the people who need them represent an important dimension of what is required from any new system. For example, a new system may be needed to make sales projections available alongside actual sales. A new system may be needed to provide information about plant efficiencies to the plant manager within a day or so. A new system may be needed because the company is becoming customer oriented instead of product oriented, and current systems cannot present data that way. Task 2: Identify Missing FunctionsIn producing both current physical data flow diagrams and essential ones, we should have revealed what processes are being carried out that do not contribute (either directly or indirectly) to the income of the enterprise. Typically these functions are required to make up for shortcomings in some current [9] physical systems, or they exist because things have always been done that way, and no one challenged that before. This includes things like re-entering data for analyses that cannot be performed by current systems, or re-entering data for the second part of a process that cannot get data from the first part.
Even if all you have is the function hierarchy, you can examine each function and ask: How is this being done? Is it being done as well as it could be? For example, the order-processing function may suffer from lack of access to important product data, hindering its ability to respond to a received request for products. That function and event, plus the currently used and currently unavailable data, constitute a functional requirement. Activities involved in the maintenance of those data, if not directly part of the order-taking process, are non-functional requirements, as are requirements for such things as backups , security, and so forth. Task 3: Propose Systems and Define Use Cases for ThemFrom the above two tasks you can begin to define the parameters of new systems. Can automation eliminate that convoluted process in the Accounting Department? Can automation improve the company's interactions with customers? Define the scope of the system in terms of the functions to be performed and the data to be handled. As mentioned above, you can use external business events and the essential activities that respond to them to define the scope of the application development project. An essential activity may be a very appropriate target for automation (or new automation). Once you have postulated a system, you can use use cases to describe exactly how the system will behave. Who are its prospective users and how will they interact with it? As defined originally by Ivar Jacobson in his 1992 book, Object-Oriented Software Engineering: A use case Driven Approach , "A use case model uses actors and use cases. These concepts are simply an aid to defining what exists outside the system (actors) and what should be performed by the system" [Jacobson, 1992]. The graphic for a use case is simply one or more stick figures, representing the actors, plus an ellipse representing a system being interacted with. Subsequent authors have elaborated on this definition to include considerable text documentation. Alistair Cockburn, for example, in his 2000 book, Writing Effective Use Cases , presents a set of detailed templates for documenting a set of actors' interactions with a prospective system. A use case does not document in detail the data flowing into and out of the system, but it does represent in its underlying documentation the interactions between the actors and the potential system. A use case is typically documented in terms of its purpose, plus the set of triggers issued by the actors and its responses to each. The set of responses is often documented in terms both of the normal responses if all goes well, and of alternative responses if something does not [Cockburn, 2000]. Step 4: Identify Requirement ConstraintsA requirement constraint limits the design choices available to meet one or more required capabilities. That is, you may want to manage inventory, but there are requirement constraints that limit how you can go about doing so. These include hardware platforms available, budgetary limits, and architectural decisions previously made. Specifically , these may include input and output constraints having to do with restrictions in the environment about how data can be entered. In a manufacturing environment, for example, terminals may have to be hardened and made immune to dust and chemicals. Also included are other design constraints , which derive from economics, existing systems, and training constraints. For example, certain technologies may be prohibitively expensive, there may be restrictions as to what data are available from feeding systems, or there may be specific requirements for the user interface. Step 5: Identify Non-functional RequirementsA non-functional requirement is a property or quality that the proposed system must have to support the functional requirements. These include such things as:
. . . and so forth. Identifying non-functional requirements involves the tasks described below: Task 1: Identify Quality RequirementsIt is not sufficient to say simply that a new system will calculate an account balance. How accurate must it be? It may be that not all information required is available. How is it to deal with that? What are the quality dimensions of the required function? Data quality may be measured on the following dimensions, among others:
Business rules ultimately control the process of entering data into systems. These address the issues of accuracy and completeness . They provide the validation tests to be applied to any data that are entered. Clearly a system's data are not of high quality unless they comply with the company's business rules. This means the business rules must be stated explicitly and then enforced appropriately. The nature of the functions being performed will determine the precision required. This is related to the accuracy issue, in that if the data are not to be very accurate, they ought not be stated to the fourth decimal place. A reasonableness test should be applied here. The expected operational procedures will determine the timeliness and accessibility of the data. Here it is necessary to articulate just how current the data are required to be (instantaneous, within a week, etc.), and how available they must be to how many people. Clarity refers to the ease with which people will understand the meaning of data. The requirement is a function of the amount of knowledge and the sophistication of the expected users of the data. Clarity will be delivered through both the reasonableness of the data structures (that is, the quality of the data models produced during analysis), and the user interface (whose quality is determined during design). Task 2: Define Response-Time RequirementsSystem requirements may also include requirements for the response time of interactive systems. There are two components to this: First of all, a behavioral response-time requirement concerns the interaction of the system with a user. In general, no matter what they are doing, users expect the computer to respond to an input within a few seconds. That response may not be delivery of an output, but it is at least an acknowledgement of the input. It is essential that, no matter what the application is, entry into the computer be immediately responded to in one way or another. The trickier one is an operational response-time requirement . If this system is replacing a manual one that required a week to produce results, and if it now takes an hour to do the same thing, this is a net benefit. It is important, in evaluating response time, that the response time required to perform a function be honestly evaluated. How soon are results required in order to achieve the function being addressed? Note that even if the data are not required immediately, behavioral response-time requirements still apply. If it is acceptable for the analysis to take longer than the second or two permitted by the behavioral response-time requirement described above, then the job should be done on a batch basis. In this case, the user's interaction should consist of submitting the batch job. It should not be necessary for the user to be imprisoned at a terminal, awaiting results, when something else could be going on at the same time. Task 3: Define Look and Feel RequirementsUltimately the look and feel of a system is determined by the designer. There may be requirements defining the boundaries of that look and feel, however. This includes specifying standards and determining the overall aesthetic for the system. Microsoft Corporation, for example, has published an excellent set of standards in its 1999 Microsoft Windows User Experience . Task 4: Define Security RequirementsSecurity may be examined in terms of three factors:
Task 5: Define Cultural and Political RequirementsIf the proposed system is to be used outside the immediate organization developing it, be sure to understand the culture of any other organizations that may be using it. This includes professional cultures ( accountants may want their screens to look different from those for advertising executives) as well as geographic ones. (The English and the Americans spell "flavo(u)r" differently.) If cultural factors are going to be a problem, this should be identified early. Political considerations include everything from what constitutes acceptable and unacceptable practices in a company to concerns about religion or political correctness. Be alert to these factors. They affect requirements. Task 6: Define Legal RequirementsTo the extent that laws apply to the environment in which your proposed system will be installed, you must be aware of them when you are defining your requirements. This may include laws about disabled access, privacy, consumer protection, and the like. Step 6: Determine Level of TechnologyThe requirements analysis phase should be carried out independent of technology. The assignment here is to determine what data and processing a business requires to carry out its objectives. Once these requirements have been stated, then the design phase can apply technology to these requirements. It is appropriate, however, at the end of the requirements analysis phase to indicate desirable technological directions to take. Steps 6, 7, and 8 of Process Five, as well as Process Six, below, begin the process of addressing the technology that ultimately will be used to implement any new system. These steps could as easily be considered at the beginning of design as at the end of analysis. The point here is that they constitute the transition from one to the other. It may be clear from the requirements exercise that the time has come for the workers each to have a personal computer. Perhaps the World Wide Web is an appropriate medium. Requirements may suggest moving from a batch-oriented mainframe to a client server network. These kinds of global decisions may be made at this point. The statements at this point, however, should be no more than general decisions recommending broad categories of technology. Step 7: Identify Capacity RequirementsAs mentioned above, the activity and data models should include measures of the " size " of each. In the case of the data model, this means, for each entity type, the number of occurrences expected. This includes the number expected initially as well as the number expected over (for example) the next five years , with a projected growth rate. In the case of the function and process models, this means a measure of how often the activity is carried out, along with some measure of its relative complexity. This information can then be used by the designer to estimate disk space and processing requirements. In this step, these statistics can be collected and summarized to get a picture of just how big the problem ahead is. (Some CASE tools, for example, have utilities that calculate the estimated required disk space from the expected size of each entity type.) Step 8: Decide Whether to Make or BuyRequirements analysis is just as important if you buy software as it is if you build it yourself. You cannot adequately evaluate software unless you have a clear idea of what it should do and what the underlying structure of its data is. Only at this later phase of the requirements analysis process can you ask whether to build the system yourself or to buy a commercial off-the-shelf [11] package from someone else. This question makes sense only after you have exhaustively analyzed the data and the processing that the new system will be required to address.
Note that if the functions to be automated are routine maintenance functions, like accounting, which are not central to your business, it is perfectly appropriate to use standard, commercial software to address them. On the other hand, if you are automating a part of the business which is central to your operationwhich is at the heart of what makes you stand out from your competitionthen you can assume that commercial software has not addressed the points that are unique to your company. In this case, you are better off developing the application yourself. Step 9: Deliverable : Requirements StatementThe deliverable from Process Six, then, is a report itemizing
 |
| | |
Team-Fly  |
| Top |
EAN: 2147483647
Pages: 129