COMP201 W2

2021-10-05

Lec4

This lec will focus on

The concepts of user and system requirements
To describe functional/non-functional requirements
To explain two techniques for describing system requirements

总结

需求列出了系统应该做什么，并定义对其运行和实施的限制
功能需要列出系统应该提供的服务
Non-functional需求限制了正在开发的系统或开发过程
用户需求是对于系统要做什么的高阶陈述

Requirements Engineering
It is the process of establishing

the services that the customer requires from a system
the constraints under which it operates and is developed

lec4-p3

正式编程前

完全了解需要被解决的问题
发现为什么问题需要被解决
决定应该涉及到什么

垃圾的需求带来诸多问题并浪费时间

Requirement

The basis for a bid for a contract <= 开发的解释
The basis for the contract itself <= 详细的定义
Example
- 懒
- 懒
- 懒
- 懒
Type of Requirement
- User
- System
- Software
Functional and Non-Functional Requirements
- Functional requirements
- Non-functional requirements
- Domain requirements
Requirements Imprecision
- Problems arise when requirements are not precisely stated
- 开发人员和客户可能以不同的方式解释需求
- 开发前应该尽可能精确需求
Completeness and Consistency
尽可能保持完整和一致
Non-Functional Requirements
- Define system properties and constraints
  - reliability
  - response time
  - storage requirements
- Process requirements
  - specified
  - mandating
  - programming language pr development
- Non-functional requirements
  more critical than functional requirements
- *Classifications
  - Product
  - Organisational
  - External
  - Performance
    很难描述精确
Requirements Measures
- add it latter
Domain Requirements
- Problems
  - Understandability
    用同一领域内的语言表达
  - Implicitness
User Requirements
- non-technical
- easy to descirbe
*Writing requirements
- mandatory requirements
- desirable requirements
*Requirements Interaction
- Confilict are common in different requirements (Functional & Non-functional)
Problem with Natural Language
- Lack of clarity
- Requirements confusion
- Requirements amalgamation
  - several different requirements may be expressed together
  - Leads to problems with testing/debugging

Lec5

Introduction to coursework 1.1 and Use case analysis

Requirements

Can be functional
Can be non-functional

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).

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.
Use -> How you use the system
Case -> an example
Functional modelling of requirements
Show the external view of the system
- (Do not model internal processes)
Show the system relative to different users of the system
Advanced Use Case Diagrams
- We can draw a box(with a label) around a set of use cases to denote the system boundary
- Inheritance can be used between actors to show that all use cases of one actor are available to the other
  Service -> Bank Staff

Include Relations 当base case被用到的时候, included use case 也被用到

If several use cases include, as part of their functionality, another use case, we have a special way show this in a use-case diagram

Extend Relation 只有当条件符合的情况才会发生

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
一个用例有两个结果就需要扩展用例

In Summary

Include
- When the other use case is always part of the main use csae
  其他的用例是主用例的一部分
Extend
- When the other use case, sometime is needed
  其他的用例有时需要

Actors(Players)
Anything external to the system which the system interacts with

Can be human
- Customer
- player
- Driver
Can be non human
- Sensor
- Payment service
- Geo location
- Robotic arm
Example: ATM machine
- Actors :
  - Customers
  - Bank staff
  - ATM service engineer
- Use cases
  - Withdraw cash
  - check balance
  - Add cash to machine
  - Check security video recoding

Full use case template

ID
Name
Description
Pre-condition
Event flow
Post-condition
Includes
Extensions
Triggers

Notes about use cases

They do NOT describe internal behaviour
Must describe behaviour with external Actors
But external Actor can be
- External system
- External hardware
- External agency

Lec-6

本节重点

Requirements engineering process
Requirements elicitation and analysis
Stakeholder
Securitys

Objectives

To describe the principal requirements enggineering 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

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.
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 doucment
1. Requirements elicitation 引出
1. Requirements analysis 分析
1. Requirements validation 验证
1. Requirements Management 管理

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

Elicitation and Analysis

Sometimes called requirements elicitation or requirements discovery
Involves technical staff working with customers to find out about the applicatin 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
Problems
Stakeholders don’t know what they really want.
Stakeholders express requirements in their own terms.
Different stakeholders may have conflicting requirements
- Staff -> easy of use
- Management -> highest security
- Patients -> change appointments easily
- management -> plan staff resoucing, reduce costs
Organisational and political factors may influence the system requirements (Data proteciton)
The requirements change during the analysis process. New stakeholders may emerge and the business environment change.

Requirements Discovery

Is hte 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, syste stakerholders and the specifications of similar systems

view point

以不同角度分析问题
相对于单一角度分析更为精准
Identification
- Providers and receicers 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

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 stakenholders and should not have pre-conceived ideas.

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

Focused Ethnography

Developed in a project studying the air traffic control
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 vasis which is no longer relevant

Security

Most modern systems have some security requirements
- Internet
- Systems often control money
- Systems nearly always contain data
- You are Legally required often to keep your system secure
- You could get sued
Security requirements of systems
- Broken down into 4 main issues
- Confidentiality 机密性
  - Usually two main options
    - Encryption
    - Permissions
  - Data must be kept secure
    - in storage
    - on the wire or wireless link
    - For as long as reasonably possible
- Integrity 完整性
  - Messages of data must not be modifiable without
    - Knowledge of the change
  - Integrity approaches
    - CRC Checking(no good, easy to forge check value)
    - Hash value over dara + secret value
      - Key distribution problem
    - Hash value over data, similar problem to CRC
    - Hash value encrypted using asymmetric cipher
      - Best approach to data
- Authentication an Authorization 认可和授权
  - Authentication (Who are you)
  - Authorization (What are you allowed to do)
  - Techniques
    - Usernames, passwords, hardware(cards, dongles),
  - Often first point of attack
- Non-repudiation 不可否认
  - May requires
    - Trusted broker, third party
    - Funding in Escrow
  - Non repudiation is built on
    - Authentication
    - Integity
    - Recording and time stamping
    - Broker style servieces
One auxiliary issue
- Availability 可用性
  - requirements
    - High availability of system
    - Specifying in 9s terminology
      从 onenine 到 six nine 的停机时间越来越短
  - practise
    - 9s terminology not always useful
    - Imagine a computer system
    - Three 9s available but unavailability spread as 78 seconds per day
    - Or Five 9s available, failing once every 10 years for 50 minutes
    - So ideally to need specify
      - Worst case scenarios
      - Worst cse delay as well as down time
      - How the system can degrade gracefully
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

Security, logs and alerts

Security is very dependent on knowledge of activity (audits and logs)
Standard log(recors all logins/logouts, database access reqursts) 标志日志
Failed login log(records all failed logins) 登录失败日志
Unusual activity log(high volume transactions on account) 活动异常日志
Alet log 警报日志
Alerts
- unusual activity can be used to alert operators, suspend accounts etc

Bell-LaPadula model

secutity clearance:
- Top-Secret(4)
- secret(3)
- Sensitive(2)
- Unclassified
no read-up
- 不能阅读比你高等级的文件
no write-down
- 一个文本不能与另一个安全级别的短文本复制
- 在敏感文件中加入秘密信息它将变成秘密信息
- 高机密等级不能生成低机密文件
Trusted subjects
- Can write documents down
- Must be shown trustworthy with regard to the security policy

Requirements Checking

Validity 有效性是否满足客户需求
Consistency 一致性确认是否有需求矛盾
Completeness 完整性是否包含客户的所有需求
Realism 现实性现有的技术是否能实现
Verifiability 是否可以检查要求

Cucumber

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