Lecture 7 Flashcards
What are some types of requirements?
User requirements: Requirements in NL, written for costumers. Statements in natural language. Diagrams of the services the system provides and operational constraints. Written for customers
System requirements: Structured document setting out descriptions of the system’s functions, services and operational constraints. May be part of contract between client and constructor
WHAT IS REQUIREMENTS ENGINEERING?
The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.
Example of functional requirements (hospital example)
User should be able to search the appointments for all clinics.
System shall generate (every day for all clinics) a list of patients that have an appointment for the day.
Each staff member using the system should be uniquely identified by an 8-digit employee number.
What is functional requirements?
Statements of services the system should provide, of how the system should react to particular inputs, and of how the system should behave in particular
situations.
* May state what the system should not do.
What is important when creating functional requirements?
Make them precise, since ambiguity of a requirement can confuse the user and the developer
What is non-functional requirements?
Non-functional requirements consists of constraints and properties, that determains how the whole system should behavie.
- Constraints on the services or functions offered by the system such as timing
constraints, constraints on the development process, standards, etc.
- Constraints on the services or functions offered by the system such as timing
- Often apply to the system as a whole rather than individual features or services.
What can make problems arise in functional requirements?
Problems arise when requirements are not precisely stated.
What are the 3 non-functional requirements in the pyramid?
- Product requirement
- Organisational requirement
- External requirement
NON-FUNCTIONAL REQUIREMENTS defines the systems properties and constraints. What are some examples of properties and constraints?
- Examples of properties are: reliability, security, response time, storage requirements, etc.
- Examples of constraints are: I/O device capability, system representations, programming language, etc
Give an example of the goal and verifiable metrics in non-functional requirement (hospital example)
Goal
- System should be easy to use by medical staff. Should be organised so user errors are minimised
Verifiable metrics
- Medical staff should be able to use all the system functions after 4 hours of training
- Average number of errors made by experienced users should not exceed 2 per hour of using the system
Can non-functional requirements be more important than functional requirements?
Yes! Non-functional requirements may be more critical than functional requirements. If these are not met, the system may be useless.
What are the 4 requirement validation things?
Complete: All needed features are in the requirements.
Consistent: No conflicting requirements.
Clear (unambiguous): No ambiguous interpretations.
Correct: Describes only intended features, not unintended ones.
What are some types of non-function requirements? (Mention atleast the three first types)
What is MoSCoW
How to prioritise requirements.
Must: Can’t do without
Should: Really want this
Could: Would like this
Won’t: Do not need/want this
(even though it might be plausible)
What is a goal in terms of non-functional requirements, why is it helpfull?
A general intention of the user such as ease of use. Goals are helpful to developers as they convey the intentions of the system user
Why do we prioritise requirements?
- It’s the basis for decision-making (technical and managerial)
- Compromises between conflicting requirements
- Plan releases of software
What is verifiable non-functional requirement, and why is it useful?
A statement using some measure that can be objectively tested. Verifiable metrics are useful in quality assurance (QA) and contract management.
What is the FURPS+ model?
Kinda a guideline to what requirements should be in your system
FURPS:
Functional
Usability
Reliability
Performance
Supportability
+:
Implementation
Interface
Operations
Packaging
Legal
…
Mention some non-functional metrics?
- Speed
- Size
- Ease of use
- Reliablity
- Robustness
- Portablity
What is requirement elicitation and analysis?
Two questions need to be answered:
* How can we identify the purpose of a system?
* What is inside, what is outside the system?
These questions are answered during requirements elicitation and analysis.
Requirements elicitation
* Definition of the system in terms understood by the customer and/or user (“Requirements specification”).
Analysis
* Definition of the system in terms understood by the developer (Technical specification, “Analysis model”).
The last validation requirements?
- Realistic
- Verifiable
- Traceable
What is requirement process?
Consists of the activities Requirements Elicitation and Analysis.
Mention some best practices when making REQUIREMENTS
- Short sentences and paragraphs
- Only one message per sentence
- Consistent terminology
- Use abbreviations sparingly
- Mark open issues (“TBD”, “TODO”)
- Avoid general terms, be concise
- Reflect on use of “shall”, “should”, “must”, “can” etc.
What questions should be asked to identify actors?
- Who uses the system to work?
- Who performs main functions?
- Who handles secondary functions (like maintenance)?
- What other systems (hardware/software) does this system connect with?
What should we remember when making:
* Scenario name
* Participating actor
* Flow of events
- Scenario name/ use case = make a name that clearly sates this scenario in a verb-phrase,
- Participating actor = actors should be named with noun phrases.
- Flow of events = Phrased in the active voice, describe how such a scenario would play out. Use around 4-6 steps, when you mention the actors, describe their role. If you mention things that are attributes in your program, write with capital letters.
pic
What types of scenarios are there?
As-is Scenario: Describes the current system. User described. Used for re-engineering.
Visionary Scenario: Describes the future system. Not done by the user or developer alone. Used in greenfield and interface engineering project.
Evaluation Scenario: User task for system evaluation.
Training Scenario: Step-by-step instructions for novice users.
What is heuristics for scenarios?
Heuristics, in this context, are rules of thumb or guidelines that help in the elicitation and specification of software requirements.
- What are the primary tasks that the system needs to perform?
- What data will the actor create, store, change, remove, or add in the system?
- What external changes does the system need to know about?
- What changes or events will the actor of the system need to be informed about?
Mention the techniques for requirement elicitation
Document analysis
Observation
Questionnaire
Interview
Focus group
Prototyping
Content of “use case”
- Name of Use Case
Actors
- Description of Actors involved in use case
Entry condition
- “This use case starts when…”
Flow of Events
- Free form, informal natural language
Exit condition
- “This use cases terminates when…”
Exceptions
- Describe what happens if things go wrong
Quality Requirements
- Nonfunctional Requirements, Constraints
What are dependencies between use cases represented with?
Use case associations. Associations are used to reduce complexity
What is refinement in use cases?
Continuous refining, rewriting, and extending (and deleting!) seeks to:
* validate (w. clients/users/customers)
* remove unambiguity
* provide sufficient details
* make them complete
* consistent
* precise (delete stuff!)
What are the types of case associations?
- Includes
- Extends
- Generalisation
Pic
What is functional decomposition?
Problem: Function in the original problem statement is too complex.
Solution: Break it into simpler functions. Decompose associated use case into shorter ones.
writing it<<include>>
Problem: There are overlaps among use cases. How can we reuse flows of events instead of duplicating them?
Solution: The includes association from use case A to use case B indicates that an instance of use case A performs all the behavior described in use case B (“A delegates to B”)
How would you draw an association for use case?
Problem: the functionality in the original problem statement needs to be extended.
Solution: an extend association from use case A to use case B
Example: “ReportEmergency” is complete by itself, but can be extended by use case “Help” for a scenario in which the user requires help
Problem: we want to factor out common (but not identical) behaviour
Solution: the child use cases inherit the behaviour and meaning of the parent use case and add or override some behaviour
How do you identify initial analysis objects?
Terms
Nouns in the use cases
Real-world entities
Real-world processes
Use cases
Data sources / sinks
Artifacts for interaction
!!ALWAYS USE APPLICATION DOMAIN TERMS (not system terms)!!
How do you identify initial non-functional requirements?
What are the MANAGING REQUIREMENTS SPECIFICATION?
Negotiating specifications & requirements with clients
* iterative process
* involves technical staff working with customers
* may involve end-users, managers, engineers involved in maintenance, domain
experts, trade unions, etc. These are called stakeholders.
Maintaining traceability
* trace/follow the development of a requirements
* manage relationship between requirement and the system implementation
(very, very difficult!)
* cross-reference between requirements, models, code, tests, etc.
Documenting requirements
* requirements analysis document (RAD)
* forms the contract w. client (very, very important!)
* needs to be subject to rigorous configuration management (baseline, …)
What is the software requirement document?
- Document that states what is required of the system developers
- Include both a definition of user requirement and a specification of the system requirements
- Not a design document
- Should set off WHAT the system should do rather than HOW it should do it
User stories: remember to ask:
WHERE ARE THE DETAILS? YOU SHALL ASK FOR DETAILS IN SMALLER SUB-STORIES
What are the 3 C’s of user stories?
Card: Stories are written on note cards. May be annotated with estimates, notes, etc.
Conversation: Details of the story, comes out during conversations with the product owner
Confirmation: Acceptance tests confirm a story was coded correctly
What does INVEST IN GOOD STORIES stand for?
Independent, negotiable, valuable, estimable, small, testable
What is the product backlog iceberg?
An iceberg where we prioritise items. As we pull of items off the icerberg, other stories move up, to take their place.
Theme: A collection of related user
stories
Epic/Saga: A larger user story (long rectangle)
