Software Engineering COMP 201 Lecturer Sebastian Coope Ashton
Software Engineering COMP 201 Lecturer: Sebastian Coope Ashton Building, Room G. 18 E-mail: coopes@liverpool. ac. uk COMP 201 web-page: http: //www. csc. liv. ac. uk/~coopes/comp 201 Lecture 6 – Requirements Engineering Processes COMP 201 - Software Engineering 1
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 COMP 201 - Software Engineering 2
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 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. COMP 201 - Software Engineering 3
Requirements Engineering Processes � 1. Requirements elicitation; �What services do the end-users require of the system? � 2. Requirements analysis; �How do we classify, prioritise and negotiate requirements? � 3. Requirements validation; �Does the proposed system do what the users require? � 4. Requirements management. �How do we manage the (sometimes inevitable) changes to the requirements document? COMP 201 - Software Engineering 4
Example Patient records system (Elicitation) 1. Talk to patients, doctors, nurses, receptionists, managers to find out Current system practise, legal restrictions DPA, problems with current system, needs for improvement, security issues, costs (Elicitation) 2. Develop draft documentation and review what is most important, what will it cost, what is the timescale, is new hardware required (Validation) 3. Send requirements to end users. Present them with Q&A. Go back to step 1, discuss requirements again (Management) 4. Have a yearly review of requirements between all stakeholders. Have a system of reviewing the cost and feasability of change to system COMP 201 - Software Engineering 5
The Requirements Engineering Process COMP 201 - Software Engineering 6
Requirements Engineering COMP 201 - Software Engineering 7
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. �Is there a simpler way of doing this (buy in software and customize) COMP 201 - Software Engineering 8
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? COMP 201 - Software Engineering 9
Elicitation and Analysis �Sometimes called requirements elicitation or requirements discovery. �Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints. �May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders. COMP 201 - Software Engineering 10
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 �Example, staff easy of use, management highest security �Patients change appointments easily, management plan staff resourcing, reduce costs �Organisational and political factors may influence the system requirements (Data protection) �The requirements change during the analysis process. New stakeholders may emerge and the business environment change. COMP 201 - Software Engineering 11
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 COMP 201 - Software Engineering 12
In the real world �Requirements often come from �Copying /modifying the requirements of other systems �Copying and fixing the requirements of a legacy system �Looking at what competitors do and improve on it �Prototyping �A lot of requirements are discovered by prototyping, so the initial requirements are often very thin COMP 201 - Software Engineering 13
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 COMP 201 - Software Engineering 14
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. COMP 201 - Software Engineering 15
Viewpoint Identification �We may identify viewpoints using �Providers and receivers of system services; �Systems that interact directly with the system being specified; �Regulations and standards; �Sources of business and non-functional requirements. �Engineers who have to develop and maintain the system; �Marketing and other business viewpoints. COMP 201 - Software Engineering 16
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. COMP 201 - Software Engineering 17
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. COMP 201 - Software Engineering 18
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. COMP 201 - Software Engineering 19
Scope of Ethnography �Requirements that are derived from the way that people actually work rather than the way in which process definitions suggest that they ought to work. �People may have “short cuts” or use their previous knowledge and experience to better perform their role which may not be evident. �As an example, an air traffic controller may switch off a conflict alert alarm detecting flight intersections. Their strategy is to ensure these planes are moved apart before problems arise and the alarms can distract them. COMP 201 - Software Engineering 20
Scope of Ethnography �Requirements that are derived from cooperation and awareness of other people’s activities. �People do not work in isolation and may share information and use dialogue with colleagues to inform decisions. �Using the previous scenario, air traffic controllers may use awareness of colleagues work to predict the number of aircraft entering their sector and thus require some visibility of adjacent sector. COMP 201 - Software Engineering 21
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 usecases by showing the sequence of event processing in the system (we shall study sequence diagrams later). COMP 201 - Software Engineering 22
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 nonhuman) 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. COMP 201 - Software Engineering 23
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. An alternate case here is something that could potentially go wrong and denotes a different course of action. COMP 201 - Software Engineering 24
Example - Article Printing Use-Case Actor Use case COMP 201 - Software Engineering 25
ATM machine �Actors �Customers �Bank staff �ATM service engineer �Use cases �Withdraw cash �Check balance �Add cash to machine �Check security video recording COMP 201 - Software Engineering 26
Example - ATM Use Case Diagram COMP 201 - Software Engineering 27
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: Bank Staff Customer COMP 201 - Software Engineering 28
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.
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.
In summary �Include �When the other use case is always part of the main use case �Extend �When the other use case, sometime is needed COMP 201 - Software Engineering 31
A Word on Extend/Include �Note the directions of the arrows in the previous two slides, they are different for each (according to whether a use case “includes” another, or “extends” it). �One of the benefits of UML diagrams is their simplicity and that they can be shown to and worked through with, customers. �This is to some extent lost by using more advanced features like “include” and “extend” relations; they should thus be used with care. COMP 201 - Software Engineering 32
� ID Full use case template � Short ID (useful for diagrams and reference) � Name � Full name � Description � Full description � Pre-condition � What must be true before the use can proceed � Event flow � Flow of behaviour that makes up this use case � Post-condition � What should be true if the use case successfully completes � Includes � What other use cases are used � Extensions � Optional behaviour � Triggers � What makes this use case happen COMP 201 - Software Engineering 33
Notes about use cases �They do NOT describe internal behaviour �Must describe behaviour with external Actors �But external Actor can be �External system (e. g. Paypal) �External hardware (e. g. smoke detector fire alarm) �External agency (e. g. Police, fire brigade) �So Use cases are always systems EXTERNAL behaviour COMP 201 - Software Engineering 34
ATM use case descriptions ID UC 1 Name Withdraw cash Description Bank customer withdraws cash from machine Pre-condition ATM in service Pre-condition ATM has sufficient cash stock Event flow 1. Include Use case 2 “Authenticate customer” 2. Choose quick cash or enter exact amount 3. Choose receipt option 4. Take cash Extension points Use case 4 “Balance too low” Triggers COMP 201 - Software Engineering 35
ATM use cases ID UC 2 Name Authenticate customer Description Bank customer withdraws cash from machine Pre-condition ATM in service Event flow 1. If user already authenticated exit from user case. 2. User enters card and PIN number 3. User re-enters PIN if PIN incorrect Extension points Use case 5 “Card stolen” Use case 6 “PIN entry failure” Triggers Authenticated service requested and user not authenticated Post-condition User is authenticated COMP 201 - Software Engineering 36
ATM use cases ID UC 3 Name Check balance Description Bank customer retrieves a balance on their account Pre-condition ATM in service Event flow 1. Include Use case 2 “Authenticate customer” 2. Choose onscreen or paper balance Extension points Use case 5 “Card stolen” Use case 6 “PIN entry failure” Triggers Authenticated service requested and user not authenticated Post-condition COMP 201 - Software Engineering 37
ATM use cases ID UC 4 Name Balance too low Description Bank customer cannot make cash withdrawal due to low balance Pre-condition Event flow 1. Customer chooses smaller amount or cancels transaction Extension points Triggers Cash chosen greater than available balance Post-condition COMP 201 - Software Engineering 38
Security �Most modern systems have some security requirements �Why? �Because �Internet �Systems often control money �Systems nearly always contain data (much of it personal) �You are legally required often to keep your system secure �You could get sued COMP 201 - Software Engineering 39
Security requirements of systems �Broken down into 4 main issues �Confidentiality �Integrity �Authentication and Authorization �Non-repudiation �One auxiliary issue �Availability (Performance security) COMP 201 - Software Engineering 40
Confidentiality requirements �Usually two main options �Encryption (hard security) �Permissions (soft security) �Data must be kept secure �In storage (final or intermediary) �On the wire or wireless link �For as long as reasonably possible COMP 201 - Software Engineering 41
Integrity Requirements �Messages or data must not be modifiable without �Knowledge of the change �Integrity approaches �CRC Checking (no good, easy to forge check value) �Hash value over data, similar problem to CRC �Hash value over data + secret value � Key distribution problem �Hash value encrypted using asymmetric cipher � Best approach to date COMP 201 - Software Engineering 42
Authentication/Authorization �Authentication �Who are you? �Authorization �What are you allowed to do? �Techniques �Usernames, Passwords, hardware (cards, dongles), Biometrics �Often first point of attack COMP 201 - Software Engineering 43
Non-repudiation issue From: Bob To: Broker Please buy lots of shares Applied IP Telecoms Security Bob subsequently denies sending the email Share Price Bob Broker COMP 201 - Software Engineering © Orbitage 2011 slide 4444
Non Repudiation in practice �May require �Trusted broker, third party �Funding in Escrow �Non repudiation is built on �Authentication �Integrity �Recording and time stamping �Broker style services COMP 201 - Software Engineering 45
Availability requirements �High availability of system �Specifying in 9 s terminology Uptime Six nines Five nines Four nines 99. 9999% 99. 99% Three nines Two nines One nine 99. 9% 99. 0% 90. 0% COMP 201 - Software Engineering Maximum Downtime per Year 31. 5 seconds 5 minutes 35 seconds 52 minutes 33 seconds 8 hours 46 minutes 87 hours 36 minutes 36 days 12 hours 46
Availability in practise � 9 s terminology not always useful �Imagine a computer system �Three 9 s available but unavailability spread as 78 seconds per day �Or Five 9 s available, failing once every 10 years for 50 minutes �So ideally to need specify �Worst case scenarios �Worst case delay as well as down time �How the system can degrade gracefully COMP 201 - Software Engineering 47
Security, logs and alerts �Security is very dependent on knowledge of activity (audits and logs) �Standard log (records all logins/logouts, database access requests) �Failed login log (records all failed logins) �Unusual activity log (high volume transactions on account) �Alert log (failed logins for top level clearance users) �Alerts �Unusual activity can be used to alert operators, suspend accounts etc. COMP 201 - Software Engineering 48
Bell–La. Padula model �All items given security clearance level � Top-Secret (4), Secret(3), Sensitive(2), Unclassified �no read-up � A subject cannot read a document above their clearance level � If I am cleared to level 2, I cannot read a level 3 or 4 document �no write-down � � � A document cannot be copied/included with another document with a lower security clearance So if I want to add a top secret to a sensitive document the result will be a top secret document If my classification is 2, I cannot produce an unclassified document �Trusted subjects � Can write documents down � Must be shown trustworthy with regard to the security policy COMP 201 - Software Engineering 49
Specifying Security �Ideally kept as open as possible to allow for �Upgrading of encryption algorithms and protocols �Security policy �Shredding documents �Secure disposal �Password reset protocols �Security training �Security audits �Standards compliance �Payment Card Industry Data Security Standard COMP 201 - Software Engineering 50
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. COMP 201 - Software Engineering 51
Scenarios �There are effectively test cases running in a given situation � So for example: �Try and withdraw cash with stolen credit card �Try and withdraw cash but machine has low cash stock �Withdraw cash with card number 3456123245677 �Etc. �Scenarios are very important as they �Show the developer by example what will happen given certain conditions �They can be used as a basis to test the software �Make things very clear and reduce ambiguity COMP 201 - Software Engineering 52
Agile Requirements Tool Example �Cucumber �Software tool used to help write requirements which are linked directly to tests �Cucumber uses a language called Gherkin which describes features… Feature: Login Feature start is not In order To prove who I am parsed but describes As a customer feature to developer I want To be able to login to the system Scenario: Login With test account 1 Given I have entered a username of account 1 And I have entered a password of pass 1234 When I click login The result should be login successful COMP 201 - Software Engineering Scenario is example for developer but also is linked to test code 53
Coupled to test code public class Login. Steps { @Given("^I have entered a username of account(\d+)$") public void i_have_entered_a_username_of_account(int arg 1) throws Throwable { throw new Pending. Exception(); } @Given("^I have entered a password of pass(\d+)$") public void i_have_entered_a_password_of_pass(int arg 1) throws Throwable { You can fetch throw new Pending. Exception(); data from } @When("^I click login$") public void i_click_login() throws Throwable { throw new Pending. Exception(); } scenario using this notation @Then("^The result should be login succesful$") public void the_result_should_be_login_succesful() throws Throwable { throw new Pending. Exception(); } } COMP 201 - Software Engineering 54
Cucumber in summary �Gives simple and clear notation to write specification �Analysts/test team and even customers can learn Gherkin and develop feature files �Step files are produced by development team �Test data can be changed later Without changing test code COMP 201 - Software Engineering 55
Lecture Key Points �The requirements engineering process includes a feasibility study, requirements elicitation and analysis, requirements specification and requirements management. �The requirements elicitation and analysis stage is iterative and involves domain understanding, requirements collection, classification, structuring, prioritisation and validation. �Systems have multiple stakeholders with different requirements �Security for most systems is a core service COMP 201 - Software Engineering 56
- Slides: 56