Download
1 / 54
540 likes | 569 Views
Learn about requirements engineering activities, techniques for elicitation and analysis, validation importance, feasibility studies, and management. Explore process variations, stakeholder engagement, and the spiral model.
E N D
Objectives • To describe the principal of requirements engineering activities and their relationship • To introduce techniques for requirements elicitation and analysis • To understand the importance of requirements validation
Topics covered • Feasibility studies • Requirements elicitation and analysis • Requirements validation • Requirements management
Requirements Engineering processes • The processes used for RE vary widely depending on the application domain, the people involved and the organization developing the requirements • However, there are a number of generic activitiescommon to all processes • Feasibility study • Requirements elicitation and analysis • requirements specification and system modeling. • Requirements validation • Requirements management
7.1 Feasibility studies • A feasibility study decides whether or not the proposed system is worthwhile • A short focused study that checks • If the system contributes to organizational objectives • If the system can be engineered using current technology and within budget • If the system can be integrated with other systems that are used
Feasibility study implementation • Based on information assessment , information collection and report writing • Questions for people in the organization • What if the system wasn’t implemented? • What are current process problems? • How will the proposed system help? • What will be the integration problems? • Is new technology needed? • What facilities must be supported by the proposed system?
7.2 Requirements Elicitation (discovery) and analysis • Involvestechnical staff working with customers, the services that the system should provide and the system’s operational constraints • May involveend-users, managers, engineersThese are called stakeholders
Problems of requirements analysis • Stakeholders don’t know what they really want • Stakeholders express requirements in their own terms • Different stakeholders may have conflicting requirements • Organizational and politicalfactors may influence the system requirements • The requirements change during the analysis process. New stakeholders may emerge and the business environment change
requirements analysis Process (activities) • Requirements collection, interact with stakeholders, domain requirements (understanding). • Classification and organization, organize requirement in a structure one (coherent cluster). • Conflict resolution, resolving the conflict. • Prioritization, prioritize requirements. • Requirements checking and documentation, checking for completion, consistency, and in accordance with what stakeholder really wants, then documented for the next phase.
7.2.1 Requirements discovery(Viewpoints, interview , scenario, use case) • The process of gathering information about the proposed and existing systems and eliciting the user and system requirements from this information. • Sources of information include documentation, system stakeholders and the specifications of similar systems.
a. Viewpoint-oriented approach • Stakeholdersrepresent different ways of looking at a problem • Viewpoints are a way of structuring the requirements to represent the perspectives of different stakeholders.. • This multi-perspective analysisis important as there is no single correct way to analyze system requirements.
Example - Banking (auto-teller system )ATM system • The example used here is an auto-teller system which provides some automated banking services • we use a very simplified system which offers some services to customers of the bank who own the system and a narrower range of services to other customers • Services include cash withdrawal, message passing (send a message to request a service), ordering a statement and transferring funds
Auto-tellerviewpoints • Bank customers • Representatives of other banks: allow other ATM to be used • Hardware and software maintenance engineers • Marketing department • Bank managers and staff • Database administrators and security staff • Communications engineers • Personnel department Stakeholder + domain + system can be represented as system viewpoints
Types (Models) of viewpoint • Interactor viewpoints • People or other systems that interact directly with the system. • In an ATM, the customer’sand the account database are interactor VPs. • Indirect viewpoints • Stakeholders who do not use the system themselves but who influence the requirements. • In an ATM, managementand security staff are indirect viewpoints. • Domain viewpoints • Domain characteristics and constraintsthat influence the requirements. • In an ATM, the standards for inter-bank communications.
Viewpoint process model • Viewpoint identification: discover viewpoints which receive system services and identify the services provided to each viewpoint using: • Providers and receivers of system services; • Systems that interact directly with the system being specified; • Regulations and standards; • Engineers who have to develop and maintain the system; • Marketing and other business viewpoints.
Viewpoint process model, cont • Viewpoint structuring, group related viewpoints into a hierarchy. Common services are provided at higher-levels in the hierarchy • Viewpoint documentation, refine the description of the identified viewpoints and services • Viewpoint-system mapping, transform the analysis to an object-oriented design
b. Interviewing • In formal or informal interviewing, the RE teamputs questions to stakeholdersabout the system. • There are two types of interview • Closed interviews where a pre-defined set of questions are answered. • Open interviews where there is no pre-defined agenda and a range of issues are explored with stakeholders.
Interviews in practice • Normally a mix of closed and open-ended interviewing. • Interviews are good for getting an overall understanding of what stakeholders do and how they interact with the system.
Effective interviewers • Interviewers should be open-minded, willing to listen to stakeholders and should not have pre- ideas about the requirements. • They should prompt the interviewee with a question or a proposal and should not simply expect them to respond to a question such as ‘what do you want’.
c. Scenarios • Scenarios are descriptions ofhow a system is used in practice, a real-life examples of how a system can be used. • Scenarios are particularly useful for adding detail to an outline requirements description
Scenario include: • description of the system state at the beginning of the scenario • Normal flow of events in the scenario • What can go wrong and how this is handled • Other concurrent activities • description of the System state on completion of the scenario
Event scenarios • Event scenarios may be used to describe how a system responds to the occurrence of some particular event such as ‘start transaction’
Event scenarios, cont… • The diagrammatic notations used in event scenarios are: • Data provided and deliveredfrom/to a viewpoint is shown in ellipses. • Control information, enter and leave at the top of each box. • Exception processing, shown at the bottom of the box. • Name of the next expected event is shown in a shaded box
Exception description • In the previous example, exceptions are: • Timeout, customer fails to enter a PIN within the allowed time limit • Invalid card, the card is not recognized and is returned • Stolen card, the card has been registered as stolen and is retained by the machine
c. Use cases • Use-cases are a scenario based technique for requirement elicitation in the UML notations that used in object-oriented system model (Unified Modelling Language) which identify the actors in an interaction and which describe the interaction itself • A set of use cases should describe all possible interactions with the system • Sequence diagrams may be used to add detail to use-cases by showing the sequence of event in the system
Use cases, cont.. • The sequence diagram (ch 6) is used to add information to use-case. • The sequence diagram shows the: 1- actors used in the interaction 2- objects that the actors interact with. 3- operation associated with these objects.
Library system , example. • Interaction for downloading and printing article. • Objects used in this interaction are: 1. Article 2. Form 3. workspace 4. printer
7.3 Requirements validation • Concerned with demonstrating that the requirements define the system that the customer really wants • Requirements error costs are high so validation is very important • Fixing a requirements errorafter deliverymay cost up to 100 times the cost of fixing an implementation error • Change requirement error means change system design and implementation
Requirements checking(types of checks should be carried out on requirements) • Validity. Does the system provide the functions which best support the customer’s needs? • Consistency. Are there any requirements conflicts? • Completeness. Are all functions required by the customer included? • Realism. Can the requirements be implemented given available budget and technology • Verifiability. Can the requirements be checked? In order to reduce potential dispute نزاع between customers. Should be write a set of test that can be demonstrate that the delivered system meet each specified requirements.
Requirements validationtechniques • Requirements reviews, systematic manual analysis of the requirements • Prototyping, using an executable model of the system to check requirements. • Test-case generation, developing tests for requirements to check testability of requirement. • Automated consistency analysis , checking the consistency of a structured requirements description, if the requirements are expressed in structured or formal notation, then CASE tool may be used to check the consistency.
6.3.1 Requirementsreviews • Regular reviews should be held while the requirements definition is being formulated • Both client and contractor staff should be involved in reviews • Reviews may be formal (with completed documents) or informal. • Good communications between developers, customers can resolve problems at an early stage
Review checks: • Verifiability. Is the requirement realistically testable? • Comprehensibility. Is the requirement properly understood? • Trace-ability. Is the source of the requirement clearly stated? • Adaptability. Can the requirement be changed without a large impact on other requirements?
7.4 Requirements management • Requirements management is the process of managing changing requirementsduring the requirements engineering process andsystem development • Requirements are inevitably incomplete and inconsistent because: • New requirements emerge during the process because business needs change and a better understanding of the system is developed • Different viewpoints have different requirements and these are often contradictory
Requirements change because of: • Thepriority of requirements from different viewpoints changes during the development process • System customers may specify requirements from a business perspective that conflict with end-user requirements. • (customers-people who pay for the system- and end-user - people who use the system- usually different) • The business and technical environment of the system changes during its development
7.4.1 Enduring and volatile requirements • Enduring requirements.Stable requirements derived from the core activity of the customer organization. E.g. a hospital will always have doctors, nurses, etc. • Volatile requirements. Requirements which changeduring development or when the system is in use. In a hospital, requirements derived from health-care policy
Classification of Volatile requirements • Mutable متقلب requirements, requirements that change due to the changing of system’s environment • Emergent requirements, requirements that emerge as understanding of the system develops during the system development.
Classification of Volatile requirements • Consequential requirements, requirements that result from the introduction of the computersystem that result to new process which may generate new requirements. • Compatibility requirements, requirements that depend on other systems
7.4.2 Requirements management planning • During the requirements engineering process, you have to plan on: • Requirements identification, how requirements are individually identified • A change management process, the process followed when analyzing a requirements change (the impact and cost of change)
Requirements management planning, cont.. • Traceability policies, the amount of information about requirements relationships are recorded and how it should be maintained • CASE toolsupport which required to help manage requirements change, using spreadsheets and databases.
Traceability • Traceability is concerned with the relationships between requirements, their sources andrelationships between requirements and the system design • There are three types of traceability: • Source traceability, links from requirements to stakeholders who proposed these requirements • Requirements traceability, links between dependent requirements • Design traceability, links from the requirements to the design,
