Software Engineering Body of Knowledge (v3) (2014) (811503), страница 7
Текст из файла (страница 7)
If,in this scenario, a customer of a particular product has specific requirements thatcompromise the potential for componentreuse, the software engineers must carefullyweigh their own stake against those of thecustomer. Specific requirements, particularly constraints, may have major impact onproject cost or delivery because they eitherfit well or poorly with the skill set of theengineers.
Important tradeoffs among suchrequirements should be identified.It will not be possible to perfectly satisfy therequirements of every stakeholder, and it is thesoftware engineer’s job to negotiate tradeoffs thatare both acceptable to the principal stakeholdersand within budgetary, technical, regulatory, andother constraints.
A prerequisite for this is that allthe stakeholders be identified, the nature of their“stake” analyzed, and their requirements elicited.2.3. Process Support and ManagementThis section introduces the project managementresources required and consumed by the requirements process. It establishes the context for thefirst topic (Initiation and Scope Definition) of theSoftware Engineering Management KA. Its principal purpose is to make the link between the process activities identified in 2.1 and the issues ofcost, human resources, training, and tools.2.4. Process Quality and ImprovementThis topic is concerned with the assessment ofthe quality and improvement of the requirementsprocess.
Its purpose is to emphasize the key rolethe requirements process plays in terms of theSoftware Requirements 1-5cost and timeliness of a software product and ofthe customer’s satisfaction with it. It will help toorient the requirements process with quality standards and process improvement models for software and systems. Process quality and improvement is closely related to both the SoftwareQuality KA and Software Engineering ProcessKA, comprising• requirements process coverage by processimprovement standards and models;• requirementsprocessmeasuresandbenchmarking;• improvement planning and implementation;• security/CIA improvement/planning andimplementation.3. Requirements Elicitation[1*, c4s5] [2*, c5, c6, c9]Requirements elicitation is concerned with theorigins of software requirements and how thesoftware engineer can collect them.
It is the firststage in building an understanding of the problemthe software is required to solve. It is fundamentally a human activity and is where the stakeholders are identified and relationships establishedbetween the development team and the customer.It is variously termed “requirements capture,”“requirements discovery,” and “requirementsacquisition.”One of the fundamental principles of a goodrequirements elicitation process is that of effective communication between the various stakeholders. This communication continues throughthe entire Software Development Life Cycle(SDLC) process with different stakeholders atdifferent points in time. Before developmentbegins, requirements specialists may form theconduit for this communication.
They must mediate between the domain of the software users (andother stakeholders) and the technical world of thesoftware engineer. A set of internally consistentmodels at different levels of abstraction facilitatecommunications between software users/stakeholders and software engineers.A critical element of requirements elicitation isinforming the project scope. This involves providing a description of the software being specifiedand its purpose and prioritizing the deliverablesto ensure the customer’s most important businessneeds are satisfied first.
This minimizes the riskof requirements specialists spending time eliciting requirements that are of low importance, orthose that turn out to be no longer relevant whenthe software is delivered. On the other hand, thedescription must be scalable and extensible toaccept further requirements not expressed in thefirst formal lists and compatible with the previousones as contemplated in recursive methods.3.1. Requirements SourcesRequirements have many sources in typical software, and it is essential that all potential sourcesbe identified and evaluated.
This topic is designedto promote awareness of the various sources ofsoftware requirements and of the frameworks formanaging them. The main points covered are asfollows:• Goals. The term “goal” (sometimes called“business concern” or “critical success factor”) refers to the overall, high-level objectives of the software. Goals provide the motivation for the software but are often vaguelyformulated. Software engineers need to payparticular attention to assessing the value(relative to priority) and cost of goals. A feasibility study is a relatively low-cost way ofdoing this.• Domain knowledge.
The software engineerneeds to acquire or have available knowledge about the application domain. Domainknowledge provides the background againstwhich all elicited requirements knowledgemust be set in order to understand it. It’sa good practice to emulate an ontologicalapproach in the knowledge domain. Relations between relevant concepts within theapplication domain should be identified.• Stakeholders (see section 2.2, ProcessActors). Much software has proved unsatisfactory because it has stressed the requirements of one group of stakeholders at theexpense of others. Hence, the deliveredsoftware is difficult to use, or subverts thecultural or political structures of the customer organization.
The software engineerneeds to identify, represent, and manage1-6 SWEBOK® Guide V3.0the “viewpoints” of many different types ofstakeholders.• Business rules. These are statements thatdefine or constrain some aspect of the structure or the behavior of the business itself. “Astudent cannot register in next semester’scourses if there remain some unpaid tuitionfees” would be an example of a business rulethat would be a requirement source for a university’s course-registration software.• The operational environment. Requirementswill be derived from the environment inwhich the software will be executed. Thesemay be, for example, timing constraintsin real-time software or performance constraints in a business environment. Thesemust be sought out actively because they cangreatly affect software feasibility and cost aswell as restrict design choices.• The organizational environment.
Softwareis often required to support a business process, the selection of which may be conditioned by the structure, culture, and internalpolitics of the organization. The softwareengineer needs to be sensitive to these since,in general, new software should not forceunplanned change on the business process.3.2. Elicitation TechniquesOnce the requirements sources have been identified, the software engineer can start elicitingrequirements information from them.
Note thatrequirements are seldom elicited ready-made.Rather, the software engineer elicits informationfrom which he or she formulates requirements.This topic concentrates on techniques for gettinghuman stakeholders to articulate requirementsrelevant information. It is a very difficult task andthe software engineer needs to be sensitized to thefact that (for example) users may have difficultydescribing their tasks, may leave important information unstated, or may be unwilling or unable tocooperate. It is particularly important to understandthat elicitation is not a passive activity and that,even if cooperative and articulate stakeholders areavailable, the software engineer has to work hardto elicit the right information.
Many business ortechnical requirements are tacit or in feedback thathas yet to be obtained from end users. The importance of planning, verification, and validation inrequirements elicitation cannot be overstated. Anumber of techniques exist for requirements elicitation; the principal ones are these:• Interviews. Interviewing stakeholders is a“traditional” means of eliciting requirements.It is important to understand the advantagesand limitations of interviews and how theyshould be conducted.• Scenarios. Scenarios provide a valuablemeans for providing context to the elicitation of user requirements.
They allow thesoftware engineer to provide a frameworkfor questions about user tasks by permitting“what if” and “how is this done” questionsto be asked. The most common type of scenario is the use case description. There is alink here to topic 4.2 (Conceptual Modeling)because scenario notations such as use casediagrams are common in modeling software.• Prototypes. This technique is a valuable toolfor clarifying ambiguous requirements. Theycan act in a similar way to scenarios by providing users with a context within which theycan better understand what information theyneed to provide. There is a wide range ofprototyping techniques—from paper mockups of screen designs to beta-test versions ofsoftware products—and a strong overlap oftheir separate uses for requirements elicitation and for requirements validation (seesection 6.2, Prototyping).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
