Requirements discovery

Requirements discovery is the process of gathering information about the proposed and existing systems and distilling the user and system requirements from this infor-mation. Sources of information during the requirements discovery phase include doc-umentation, system stakeholders and specifications of similar systems. You interact with stakeholders through interviews and observation, and may use scenarios and prototypes to help with the requirements discovery. In this section, I discuss an approach that helps ensure you get broad stakeholder coverage when discovering requirements, and I describe techniques of requirements discovery including inter-viewing, scenarios and ethnography. Other requirements discovery techniques that

7.2 • Requirements E!licitation and analysis 149

may be used include structured analysis methods covered in Chapter 8, and sys-tem prototyping, covered in Chapter 17.

Stakeholders range from system end-users through managers and external stake-holders such as regulators who certify the acceptability of the system. For exam-ple, system stakeholders for a bank ATM include:

I. Current bank customers who receive services from the system

2. Representatives from other banks who have reciprocal agreements that allow each other's ATMs to be used

3.

Managers ofbank brancheswho obtainmanagemc~nt information from the system 4. Counter staff at bank brancheswho are involved in the day-to-day running of

the system

5. Database administratorswho are responsible for integrating the system with the b,mk's customer database

6. Bank security managerswho must ensure that the system will not pose a secu-rity hazard

7. The bank's marketing departmentwho are likely be interested in using the sys-tem as a means of marketing the bank

8. Hardware and software maintenance engineerswho are responsible for main-taining and upgrading the hardware and software

9. National banking regulatorswho are responsible for ensuring that the system conforms to banking regulations

In addition to system stakeholders" we have already seen that requirements may come from the application domain and from other systems that interact with the system being specified. All of these must be considered during the requirements elicitation process.

These requirements sources (stakeholders, domain, systems) can all be represented as system viewpoints, where each viewpoint presents a sub-set of the requirements for the system. Each viewpoint provides a fresh perspective on the system, but these

perspectivl~s are not completely indep<:ndent--they usually overlap so that they have

<;ommon requirements.

Viewpoil1lts

Viewpoint-oriented approaches to requirements I~ngineering (Mullery, 1979;

Finkelstein et al., 1992; Kotonya and Sommerville, 1992; Kotonya and Sommerville, 1996) organise both the elicitation proct:ss and the requirements themselves using view-points. A key strength of viewpoint-oriented analysis is that it recognises multiple per-spectives and provides a framework for discovering confliictsinthe requirements proposed by different stakeholders.

150

Chapter 7 Requirements engineering processes

Viewpoints can be used as a way of classifying stakeholders and other sources of requirements. There are three generic types of viewpoint:

1. Interactor viewpointsrepresent people or other systems that interact directly with the system. In the bank ATM system, examples of interactor viewpoints are the bank's customers and the bank's account database.

2. Indirect viewpointsrepresent stakeholders who do not use the system themselves but who influence the requirements in some way. In the bank ATM system, examples of indirect viewpoints are the management of the bank and the bank security staff.

3. Domain viewpointsrepresent domain characteristics and constraints that influ-ence the system requirements.Inthe bank ATM system, an example of a domain viewpoint would be the standards that have been developed for interbank com-munications.

Typically, these viewpoints provide different types of requirements. Interactor viewpoints provide detailed system requirements covering the system features and interfaces. Indirect viewpoints are more likely to provide higher-level organisational requirements and constraints.

Domain

viewpoints normally provide domain constraints that apply to the system.

The initial identification of viewpoints that are relevant to a system can some-times be difficult. To help with this process, you shouldtryto identify more spe-cific viewpoint types:

l. Providers of services to the system and receivers of system services 2. Systems that should interface directly with the system being specified 3. Regulations and standards that apply to the system

4. The sources of system business and non-functional requirements

5. Engineering viewpoints reflecting the requirements of people who have to develop, manage and maintain the system

6. Marketing and other viewpoints that generate requirements on the product fea-tures expected by customers and how the system should reflect the external image of the organisation

Almost all organisational systems must interoperate with other systems in the organisation. When a new system is planned, the interactions with other systems must be planned. The interfaces offered by these other systems have already been designed. These may place requirements and constraints on the new system.

Furthermore, new systems may have to conform to existing regulations and stan-dards, and these constrain the system requirements.

7.2 • Requirements elicitation and analysis 151

·---1---. ~

/

I"L ^j 0a

Figure7.4

Viewpoints in L1BSYS

•

AsI discussed earlier in thechaptl~r, you should identify high-level business and non-functilOnal requirements early in the RE process. The sources of these require-ments maybeuseful viewpoints in a more detailed process. They maybeable to expand and develop the high-level requirements into more specific system requirements.

Engineering viewpoints maybeimportant for two reasons. Firstly, the engineers developing the system may have experience with similar systems and may be able to suggest requirements from that experience. Secondly, technical staff who have to manage and maintain the system may have requirements that will help simplify system support. System manageme.nt requirements are increasingly important because system management costs ar,e an increasing proportion of the total lifetime eosts for a system.

Finally, viewpoints that provide requirements may come from the marketing and externalaffairs departments in an org;misation. This is especially true for web-based systems, particularly e-commerce systems and shrink-wrapped software products.

Web-based systems must present a favourable image of the organisation as well as deliver functionality to the user. For software products, the marketing department should know what system features will make the system more marketable to potential buyers.

For any non-trivial system, there are a huge number of possible viewpoints, and lit is practically impossible to elicit requirements from all of them. Therefore, it is Important that you organise and structure the viewpoints into a hierarchy.

Viewpoims in the same branch are likely to share common requirements.

As an illustration, consider the viewpoint hierarchy shown in Figure 7.4. This is a relatively simple diagram of the viewpoints that may be consulted in deriving the requirements for the LIBSYS system. You can see Khat the classification of inter-actor, indirect and domain viewpoints helps identify sources of requirements apart from the immediate users of the system.

152 Chapter 7 • Requirements engineering processes

Once viewpoints have been identified and structured, you shouldtryto identify the most important viewpoints and start with them when discovering system requirements.

Interviewing

Formal or informal interviews with system stakeholders are part of most requirements engineering processes. In these interviews, the requirements engineering team puts questions to stakeholders about the system that they use and the system to be devel-ped. Requirements are derived from the answers to these questions. Interviews may be of two types:

1. Closed interviews where the stakeholder answers a predefined set of questions.

2. Open interviews where there is no predefined agenda. The requirements engi-neering team explores a range of issues with system stakeholders and hence develops a better understanding of their needs.

In practice, interviews with stakeholders are normally a mix of these. Th answers to some questions may lead to other issues that are discussed in a less struc-tured way. Completely open-ended discussions rarely work well; most interviews require some questions to get started and to keep the interview focused on the sys-tem to be developed.

Interviews are good for getting an overall understanding of what stakeholders do, how they might interact with the system and the difficulties that they face with current systems. People like talking about their work and are usually happy to get involved in interviews. However, interviews are not so good for understanding the requirements from the application domain.

Itis hard to elicit domain knowledge during interviews for two reasons:

1. All application specialists use terminology and jargon that is specific to a domain.

Itis impossible for them to discuss domain requirements without using this ter-minology. They normally use terminology in a precise and subtle way that is easy for requirements engineers to misunderstand.

2. Some domain knowledge is so familiar to stakeholders that they either find it difficult to explain or they think it is so fundamental that it isn't worth men-tioning. For example, for a librarian, it goes without saying that all acquisitions are catalogued before they are added to the library. However, this may not be obvious to the interviewer so it isn't taken into account in the requirements.

Interviews are not an effective technique for eliciting knowledge about organi-sational requirements and constraints because there are subtle power and influence relationships between the stakeholders in the organisation. Published organisational structures rarely match the reality of decision making in an organisation, but

7.2 • Requirements elicitation and analysis 153

interviewees may not wish to reveal the actual rather than the theoretical structure to a stranger. In general, most people are reluctant to discuss political and organi-sational issues that may affect the requirements.

Effective interviewers have two characteristics:

I. They are open-minded, avoid preconceived ideas about the requirements and are willing to listen to stakeholders. Ifthe stakeholder comes up with surpris-ing requirements, they are willsurpris-ing to change their mind about the system.

2. They prompt the interviewee to start discussions with a question, a requirements proposal or by suggesting working together on a prototype system. Saying to people 'tell me what you want' is unlikely to result in useful information. Most people find it much easier to talk in a defined context rather than in general terms.

Information from interviews supplements other information about the system from documents, user observations, and so on. Sometimes, apart from informa-tion from documents, interviews may be the only source of informainforma-tion about the system requirements. However, interviewing on its own is liable to miss essen-tial information, so it should be used alongside other requirements elicitation techniques.

Scenarios

People usually find it easier to relate to real-life examples than to abstract descrip-tions. They can understand and critique a scenario of how they might interact with a software system, Requirements engineers can use the information gained from this discussion to formulate the actual system requirements.

Scenanos can be particularly useful for adding detail to an outline requirements description. They are descriptions of example interaction sessions. Each scenario covers one or more possible interactions. Several fonns of scenarios have been devel-oped,ea,~h of which provides different types of information at different levels of detail about the system. Using scenarios to describe requirements is an integral part of agile methods, such as extreme programming, that I discuss in Chapter 17.

The scenario starts with an outline of the interaction, and, during elicitation, details are added to create a complete description of that interaction. At its most general, a scenano may include:

I. A description of what the system and users expect when the scenario starts 2. A description of the normal flow of events in the scenario

3, A description of what can go wrong and how this is handled

4. Information about other activities that might be going on at the same time 5. A description of the system state when the sCf:nario finishes.

154 Chapter 7 • Requirements engineering processes

Figure 7.5 Scenario for article downloading in L1BSYS

... ...,...: The user has logged on to the UBSYS system and has located the journal containing the copyofthe article.

NormIII:The user selects the article to be copied. The system prompts the user to provide subscriber information for the journal or to indicate a methodofpayment for the article. Payment can be madebycredit card or by quoting an organisational account number.

The user is then asked to fill in a copyright form that maintains details of the transaction and submit it to the L1BSYS system.

The copyright form is checked and, ifitis approved, the PDF version of the article is downloadedtothe L1BSYS working area on the user's computer and the user is informed that it is available.Theuser is asked to select a printer and a copy of the article is printed. If the article has been flagged as 'print-only'itis deleted from the user's system once the user has confirmed that printingiscomplete.

WINItcanp wronl:The user may fail to fill in the copyright form correctly. In this case, the form should be re-presented to the user for correction. If the resubmitted form is still incorrect, then the user's request for the articleisrejected.

The payment may be rejectedbythe system, in which case the user's request for the article is rejected.

The article download may fail, causing the systemtoretry until successful or the user terminates the session.

It may not be possible to print the article. If the articleisnot flagged as 'print-only' it is held in the L1BSYS workspace. Otherwise, the article is deleted and the user's account creditedwiththe costofthe article.

0lIMr·1ICIIvItIeI:Simultaneous downloads of other articles.

SysIHI . . . .onCNIpIeIIon:Userislogged on. The downloaded article has been deleted from L1BSYS workspace if it has been flagged as print-only.

Scenario-based elicitation can be carried out infonnally, where the requirements engineer works with stakeholders to identify scenarios and to capture details of these scenarios. Scenarios may be written as text, supplemented by diagrams, screen shots, and so on. Alternatively, a more structured approach such as event scenarios or use-cases may be adopted.

As an example of a simple text scenario, consider how a user of the LIBSYS library system may use the system. This scenario is shown in Figure 7.5. The user wishes to print a personal copy of an article in a medical journal. This journal makes copies of articles available free to subscribers, but nonsubscribers have to pay a fee per article. The user knows the article, title and date of publication.

Use-cases

Use-cases are a scenario-based technique for requirements elicitation which were first introduced in the Objectory method (Jacobsen, et al., 1993). They have now

Figure 7.6 Asimple use-case for article printing

•

7.2 • Requirements elicitation and analysis 155

Article priinting

become a fundamental feature of the UML notation for describing object-oriented system models. In their simplest form, a use-case lldentifies the type of interaction and the actors involved. For example, Figure 7.6 shows the high-level use-case of the article printing facility in LIBSYS described in Figure 7.5.

Figure 7.6 illustrates the essentials of the use-case notation. Actors in the pro-cess are represented as stick figures, and each class of interaction is represented as a named ellipse. The set of use-cases represents aJll of the possible interactions to be represented in the systemrequin~ments.Figure 7.7 develops the LIBSYS exam-ple and :,hows other use-cases in that environment.

There is sometimes confusion about whether a use-case is a scenario on its own or, as suggested by Fowler (Fowler and Scott, 1997), a use-case encapsulates a set of scenarios, and each scenario is a single thread through the use-case.Ifa scenario includes multiple threads, there would be a scenario for the normal interaction plus scenario, for each possible exception.

Use-cases identify the individual interac:tions with the system. They can be doc-umented with text or linked to UML models that develop the scenario in more detail.

Sequence diagrams (introduced in Chapter 6) are often used to add information to a use-case. These sequence diagrarns show the actors involved in the interaction, the objects they interact with and the operations associated with these objects.

As an illustration of this, Figun: 7.8 shows th(: interactions involved in using LIBSYS for downloading and printing an article.InFigure 7.8, there are four objects of classes-Article, Form, Workspace and Printer-·involved in this interaction. The sequence of actions is from top to bottom, and the labels on the arrows between the actors and objects indicate the names of operations. Essentially, a user request for an article triggers a request for a copyright fonn. Once the user has completed the fonn, the article is downloaded and sent to th(: printer. Once printing is com-plete, th.: article is deleted from the LIBSYS workspace.

The UML is ade facto standard for object-oriented modelling, so use-cases and use-case-based elicitation is increasingly used for requirements elicitation. Other types of UML models are discussed! in Chapter 8, which covers system modelling, and in Chapter 14, which covers object-oriented design.

Scenarios and use-cases are effective technique:s for eliciting requirements for interactor viewpoints, where each type of interaction can be represented as a use-case. They can also be used in cor~unction with some indirect viewpoints where these viewpoints receive some results (such as a management report) from the sys-tem. However, because they focus on interactions, they are not as effective for elic-iting constraints or high-level business and non-functional requirements from indirect viewpoints or for discovering domain requirements.

156 Chapter 7 • Requirements engineering processes

Figure 7.7 Use cases for the library system

Ubrary User

Supplier

Ubrary Staff

Figure 7.8 System interactions for artide printing

User

litem:

_Artide ^I~nter:_Printer

0

^request

I...

^request

I

^complete

r-I ^retum

I~

^copyrightOK

deliver

articleOK

print send

II

^inform

^,1

^confirm

I

delete

7.2 • Requirements elicitation and analysis 157

7.2.2

Ethnography

Software systems do not exist in isolation--they arl~used in a social and organisa-tional context, and software system requirements may be derived or constrained by that context. Satisfying these social and organisational requirements is often criti-cal for the success of the system. One reason why many software systems are deliv-ered but never used is that they do not take proper account of the importance of these reo uirements.

Ethnographyis an observational technique that can be used to understand social and organisational requirements. An analyst immerses him or herself in the work-ing environment where the system willbeused. He: or she observes the day-to-day work and notes made of the actual tasks in which participants are involved. The value of ethnography is that it helps analysts discover implicit system requirements that reflect the actual rather than the fonnal processes ill which people are involved.

People often find it very difficult to articulate dl:tails of their work because it is

People often find it very difficult to articulate dl:tails of their work because it is

在文檔中 Engineering Software (頁 173-183)