Requirements Engineering Processes in Software Engineering, Slides of Software Engineering

Download Requirements Engineering Processes in Software Engineering and more Slides Software Engineering in PDF only on Docsity! Objectives  To describe the principal requirements engineering activities and their relationships  To introduce techniques for requirements elicitation and analysis  To describe requirements validation and the role of requirements reviews  To discuss the role of requirements management in support of other requirements engineering processes 1 COMP201 - Software Engineering docsity.com Requirements Engineering Processes  The processes used for requirements engineering vary widely depending on the application domain, the people involved and the organisation developing the requirements.  However, there are a number of generic activities common to all processes which we look at today.  The goal of this stage of the software engineering process is to help create and maintain a system requirements document. 2 COMP201 - Software Engineering docsity.com Requirements Engineering Requirements specification Requirements validation Requirements elicitation Sy stem requirements specification and modeling Sy stem requirements elicitation User requirements specification User requirements elicitation Business requirements specification Prototy ping Feasibility study Reviews Syst em requirements document 5 COMP201 - Software Engineering docsity.com 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 organisational 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. 6 COMP201 - Software Engineering docsity.com Feasibility Study Implementation  Based on information assessment (what is required), information collection and report writing.  Questions for people in the organisation  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 skills?  What facilities must be supported by the proposed system? 7 COMP201 - Software Engineering docsity.com 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 information.  Sources of information include documentation, system stakeholders and the specifications of similar systems. 10 COMP201 - Software Engineering docsity.com Example - ATM Stakeholders  Bank customers  Representatives of other banks  Bank managers  Counter staff  Database administrators  Security managers  Marketing department  Hardware and software maintenance engineers  Banking regulators 11 COMP201 - Software Engineering docsity.com Viewpoints  Viewpoints are a way of structuring the requirements to represent the perspectives of different stakeholders. Stakeholders may be classified under different viewpoints.  This multi-perspective analysis is important as there is no single correct way to analyse system requirements. 12 COMP201 - Software Engineering docsity.com Interviewing  In formal or informal interviewing, the RE team puts questions to stakeholders about the system that they use and the system to be developed.  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.  Ideally, interviewers should be open-minded, willing to listen to stakeholders and should not have pre-conceived ideas. 15 COMP201 - Software Engineering docsity.com Ethnography  In ethnography, a social scientist spends a considerable amount of time observing and analysing how people actually work.  People do not have to explain or articulate their work.  Social and organisational factors of importance may be observed.  Ethnographic studies have shown that work is usually richer and more complex than suggested by simple system models. 16 COMP201 - Software Engineering docsity.com Focused Ethnography  Developed in a project studying the air traffic control process  Combines ethnography with prototyping  Prototype development results in unanswered questions which focus the ethnographic analysis.  The problem with ethnography is that it studies existing practices which may have some historical basis which is no longer relevant. 17 COMP201 - Software Engineering docsity.com Use Cases  Use-Cases are a scenario based technique in the Unified Modeling Language (UML) 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 processing in the system (we shall study sequence diagrams later). 20 COMP201 - Software Engineering docsity.com Use Cases  In a use-case diagram, an actor is a user of the system (i.e. Something external to the system; can be human or non- human) acting in a particular role.  A use-case is a task which the actor needs to perform with the help of the system, e.g., find details of a book or print a copy of a receipt in a bookshop. 21 COMP201 - Software Engineering docsity.com Use Cases  The details of each use case should also be documented by a use case description: E.g.,  Print receipt – A customer has paid for an item via a valid payment method. The till should print a receipt indicating the current date and time, the price, the payment type and the member of staff who dealt with the sale.  [Alternate Case] – No print paper available – Print out “Please enter new till paper” to the cashier’s terminal. Try to print again after 10 seconds. COMP201 - Software Engineering 22 An alternate case here is something that could potentially go wrong and denotes a different course of action. docsity.com Advanced Use Case Diagrams  We can draw a box (with a label) around a set of use cases to denote the system boundary, as on the previous slide (“library system”).  Inheritance can be used between actors to show that all use cases of one actor are available to the other: COMP201 - Software Engineering 25 BankClerk BusinessCustomer docsity.com Include Relations  If several use cases include, as part of their functionality, another use case, we have a special way to show this in a use-case diagram with an <<include>> relation. COMP201 - Software Engineering 26 Place Order Track Order Ship Order Validate Customer <<include>> <<include>> <<include>> Seller Shopping System We must validate customer to do the other three tasks.. docsity.com Extend Relations  If a use-case has two or more significantly different outcomes, we can show this by extending the use case to a main use case and one or more subsidiary cases. COMP201 - Software Engineering 27 Ship Order Seller Shopping System Ship Partial Order <<extend>> Cancel Order <<extend>> Main case Subsidiary (alternate) cases, if the main case is not completed successfully. docsity.com LIBSYS Scenario (1) Initial assumption: The user has logged on to the LIBSYS system and has located the journal containing the copy of the article. Normal: The user selects the article to be copied. He or she is then prompted by the system to ei ther provide subscriber information for the journal or to indicate how they will pay for the article. Alternative payment methods are by credit 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 they then submit this to the LIBSYS system. The copyright fo rm is checked and, if OK, the PDF version of the article is downloaded to the LIBSYS working area on the userÕs computer and the user is informed that it is available. The user is asked to select a printer and a copy of the article is printed. If the article has been flagged as Ōprint-onlyÕ it is deleted from the userÕs system once the user has confirmed that printing is complete. 30 COMP201 - Software Engineering docsity.com LIBSYS Scenario (2) What can go wrong: The user may fail to fill in the copyright form correctly. In this case, the fo rm should be re-presented to the user for correction. If the resubmitted form is still incorrect then the userÕs request for the article is rejected. The payment may be rejected by the system. The userÕs request for the article is rejected. The article download may fail. Retry until successful or the user terminates the session. It may not be possible to print the article. If the article is not flagged as Ōprint-onlyÕ then it is held in the LIBSYS workspace. Otherwise, the article is deleted and the userÕs account credited with the cost of the article. Other activities: Simultaneous downloads of other articles. System state on completion: User is logged on. The downloaded article has been deleted from LIBSYS workspace if it has been flagged as print-only. 31 COMP201 - Software Engineering docsity.com Requirements Checking  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?  This reduces the potential for disputes between customers and contractors and a set of tests should be possible. 32 COMP201 - Software Engineering docsity.com