Requirements Engineering Processes

Question 1

Requirements Engineering Processes

Answer 1

To help create and maintain a system requirements document.

Question 2

Requirements Elicitation

Answer 2

What services to the end-users require of the system?

Question 3

Requirements Analysis

Answer 3

How do we classify, prioritise and negotiate requirements?

Question 3

Requirements Validation

Answer 3

Does the proposed system do what the users require?

Question 3

Requirements Management

Answer 3

How do we manage the changes to the requirements document?

Question 3

Feasibility Study

Answer 3

Decides whether or not the proposed system is worthwhile.

Question 4

What does feasibility study check?

Answer 4

• system contribution to organisational objectives
• if the system can be engineered using current tech/budget
• if the system can be integrated with other systems that are used
• is there a simpler way of doing this?

Question 5

Staffing for requirement analysis and elicitation…

Answer 5

Involves working with technical staff to find out about application domain, services and constraints.

Question 6

Problems with analysis and elicitation

Answer 6

• stakeholders do not know what they want
• stakeholders express requirements in their own terminology.
• conflicting requirements between stakeholders
• the domain/political factors may effect the requirements (data protection)
• requirements are subject to change

Question 7

Requirements Discovery

Answer 7

Process of gathering information about proposed and existing systems and distilling user and system requirements from this information (source of info could include documentation, system stakeholders, specifications of other systems etc).

Question 8

Requirements typically come from…

Answer 8

• Copying and modifying requirements from other systems
• Copying and fixing requirements of legacy system
• Looking at competitors

Question 9

Prototyping

Answer 9

Requirement are also discovered from protypes, therefore the initial requirements are thin since they are discovered from improving prototypes.

Question 10

Viewpoints

Answer 10

Structures the requirements to represent the perspectives from different stakeholders.

Question 11

Types of interviews

Answer 11

Closed Interview -> pre-defined set of questions are answered
Open Interview -> no pre-defined agenda, and range of issues are explored with stakeholder

Question 12

Ethnography

Answer 12

A social scientist spends time observing and analysing how people ACTUALLY work in the workplace.

Question 13

Focused Ethnography

Answer 13

Combines ethnography with prototyping, with prototype development resulting in unanswered questions which focus the ethnographic analysis.

Question 14

Scope of Ethnography

Answer 14

Derive requirements from how people work compared how we presume they work.

Question 15

Security Requirements (4 main issues)

Answer 15

• Confidentiality
• Integrity
• Authentication and Authorisation
• Non-repudiation
  (BONUS: availability)

Question 16

Confidentiality Requirements (hard/soft security and how data is kept secure)

Answer 16

Hard security -> encryption
Soft security -> permissions
Data is kept secure either in storage or on the wire/wireless link for as long as reasonably possible

Question 17

Integrity Requirements

Answer 17

Messages or data must not be modified without knowledge of the change.

Question 18

How to check for integrity

Answer 18

• CRC checking (not really that good however, easy to forge the check value)
• Hash value over data (similar issue to CRC however)
• Hash value over data + secret value (key distribution problem, have to constantly exchange the key somehow)
• Hash value encrypted using asymmetric cipher (best approach to date, see public key infrastructure)

Question 19

Authentication and Authorisation Requirements

Answer 19

Usernames and passwords, verification etc

Question 20

Non-repudiation Requirements

Answer 20

Ensures nobody can deny origin or authenticity of a message/some way of communication.

Question 21

How to check for non-repudiation

Answer 21

• trusted broker, third party
• Funding in Escrow (funding into a trusted back etc)

Question 22

Availability Requirements

Answer 22

High availability of the system.

Question 23

9s Terminology

Answer 23

s

Question 24

Standard Log

Answer 24

Records all logins/logouts as well as database access requests

Question 25

Failed Login

Answer 25

Record of all failed login attempts

Question 26

Unusual Activity Log

Answer 26

High volume transactions on account

Question 27

Alter Log

Answer 27

Failed attempt for top level clearance users

Question 28

Bell-LaPadula Model

Answer 28

All items are given a security clearance, and whatever security clearance level you are in is the one you only have permission to. There are certain circumstances that you could possibly read-down (read items from a previous security level, aka less important documents) but that it only for trusted subjects.

Question 29

Duration for specifying the security

Answer 29

Should be kept open as long as possible for upgrading encryption and protocols.

Question 30

Security Policy list (how to dispose of information etc)

Answer 30

• Shredding documents
• Secure disposal
• Password reset protocols
• Security training
• Security Audits

Question 31

Validity

Answer 31

Does the system provide the functions which support customer needs?

Question 32

Consistency

Answer 32

Are there any requirement conflicts?

Question 33

Completeness

Answer 33

Are all functions by the customer included?

Question 34

Realism

Answer 34

Can the requirements be implemented given the available budget and tech?

Question 35

Verifiability

Answer 35

Can the requirements be checked?

Question 36

Scenarios

Answer 36

Test cases running in a given situation, allowing developers to see the outcome and improve on it, allowing the test to be used as a basis for the software testing.

Question 37

Agile Requirement Tool Example

Answer 37

Cucumber
Used to help write requirements which are directly linked to tests.
Uses a language called Gherkin which describes features.
Gives clear notation to write specification.
Test team and customers can learn Gherkin.
Step files are produced by development team.
Test data can be changed later without changing test code.