Requirements Engineering Processes Flashcards
Requirements Engineering Processes
To help create and maintain a system requirements document.
Requirements Elicitation
What services to the end-users require of the system?
Requirements Analysis
How do we classify, prioritise and negotiate requirements?
Requirements Validation
Does the proposed system do what the users require?
Requirements Management
How do we manage the changes to the requirements document?
Feasibility Study
Decides whether or not the proposed system is worthwhile.
What does feasibility study check?
- 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?
Staffing for requirement analysis and elicitation…
Involves working with technical staff to find out about application domain, services and constraints.
Problems with analysis and elicitation
- 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
Requirements Discovery
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).
Requirements typically come from…
- Copying and modifying requirements from other systems
- Copying and fixing requirements of legacy system
- Looking at competitors
Prototyping
Requirement are also discovered from protypes, therefore the initial requirements are thin since they are discovered from improving prototypes.
Viewpoints
Structures the requirements to represent the perspectives from different stakeholders.
Types of interviews
Closed Interview -> pre-defined set of questions are answered
Open Interview -> no pre-defined agenda, and range of issues are explored with stakeholder
Ethnography
A social scientist spends time observing and analysing how people ACTUALLY work in the workplace.
Focused Ethnography
Combines ethnography with prototyping, with prototype development resulting in unanswered questions which focus the ethnographic analysis.
Scope of Ethnography
Derive requirements from how people work compared how we presume they work.
Security Requirements (4 main issues)
- Confidentiality
- Integrity
- Authentication and Authorisation
- Non-repudiation
(BONUS: availability)
Confidentiality Requirements (hard/soft security and how data is kept secure)
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
Integrity Requirements
Messages or data must not be modified without knowledge of the change.
How to check for integrity
- 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)
Authentication and Authorisation Requirements
Usernames and passwords, verification etc
Non-repudiation Requirements
Ensures nobody can deny origin or authenticity of a message/some way of communication.
How to check for non-repudiation
- trusted broker, third party
- Funding in Escrow (funding into a trusted back etc)
Availability Requirements
High availability of the system.
9s Terminology
s
Standard Log
Records all logins/logouts as well as database access requests
Failed Login
Record of all failed login attempts
Unusual Activity Log
High volume transactions on account
Alter Log
Failed attempt for top level clearance users
Bell-LaPadula Model
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.
Duration for specifying the security
Should be kept open as long as possible for upgrading encryption and protocols.
Security Policy list (how to dispose of information etc)
- Shredding documents
- Secure disposal
- Password reset protocols
- Security training
- Security Audits
Validity
Does the system provide the functions which support customer needs?
Consistency
Are there any requirement conflicts?
Completeness
Are all functions by the customer included?
Realism
Can the requirements be implemented given the available budget and tech?
Verifiability
Can the requirements be checked?
Scenarios
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.
Agile Requirement Tool Example
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.
