Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Software Development and Software Engineering > Lecture 7 > Flashcards

Lecture 7 Flashcards

1
Q

What are some types of requirements?

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

WHAT IS REQUIREMENTS ENGINEERING?

A

The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Example of functional requirements (hospital example)

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

What is functional requirements?

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

What is important when creating functional requirements?

A

Make them precise, since ambiguity of a requirement can confuse the user and the developer

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

What is non-functional requirements?

A

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.
  • Often apply to the system as a whole rather than individual features or services.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

What can make problems arise in functional requirements?

A

Problems arise when requirements are not precisely stated.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

What are the 3 non-functional requirements in the pyramid?

A
  • Product requirement
  • Organisational requirement
  • External requirement
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

NON-FUNCTIONAL REQUIREMENTS defines the systems properties and constraints. What are some examples of properties and constraints?

A
  • Examples of properties are: reliability, security, response time, storage requirements, etc.
  • Examples of constraints are: I/O device capability, system representations, programming language, etc
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Give an example of the goal and verifiable metrics in non-functional requirement (hospital example)

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Can non-functional requirements be more important than functional requirements?

A

Yes! Non-functional requirements may be more critical than functional requirements. If these are not met, the system may be useless.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

What are the 4 requirement validation things?

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

What are some types of non-function requirements? (Mention atleast the three first types)

A

Pic

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

What is MoSCoW

A

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)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

What is a goal in terms of non-functional requirements, why is it helpfull?

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Why do we prioritise requirements?

A
  • It’s the basis for decision-making (technical and managerial)
  • Compromises between conflicting requirements
  • Plan releases of software
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

What is verifiable non-functional requirement, and why is it useful?

A

A statement using some measure that can be objectively tested. Verifiable metrics are useful in quality assurance (QA) and contract management.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

What is the FURPS+ model?

A

Kinda a guideline to what requirements should be in your system
FURPS:
Functional
Usability
Reliability
Performance
Supportability

+:
Implementation
Interface
Operations
Packaging
Legal
…

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Mention some non-functional metrics?

A
  • Speed
  • Size
  • Ease of use
  • Reliablity
  • Robustness
  • Portablity
20
Q

What is requirement elicitation and analysis?

A

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

21
Q

The last validation requirements?

A
  • Realistic
  • Verifiable
  • Traceable
22
Q

What is requirement process?

A

Consists of the activities Requirements Elicitation and Analysis.

23
Q

Mention some best practices when making REQUIREMENTS

A
  • 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.
24
Q

What questions should be asked to identify actors?

A
  • 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?

Her

25
Q

What should we remember when making:
* Scenario name
* Participating actor
* Flow of events

A
  • 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
26
Q

What types of scenarios are there?

A

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.

27
Q

What is heuristics for scenarios?

A

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?
28
Q

Mention the techniques for requirement elicitation

A

Document analysis
Observation
Questionnaire
Interview
Focus group
Prototyping

29
Q

Make sense of this compared to the written scenario

A
30
Q

Content of “use case”

A
  • 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

31
Q

What are dependencies between use cases represented with?

A

Use case associations. Associations are used to reduce complexity

32
Q

What is refinement in use cases?

A

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

33
Q

What are the types of case associations?

A
  • Includes
  • Extends
  • Generalisation
    Pic
34
Q

What is functional decomposition?

A

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

Her

35
Q

Problem: There are overlaps among use cases. How can we reuse flows of events instead of duplicating them?

A

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

36
Q

How would you draw an association for use case?

A

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

Her

37
Q

Problem: we want to factor out common (but not identical) behaviour

A

Solution: the child use cases inherit the behaviour and meaning of the parent use case and add or override some behaviour

38
Q

How do you identify initial analysis objects?

A

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

39
Q

Explain why this makes sense

A
40
Q

How do you identify initial non-functional requirements?

A

Her

41
Q

What are the MANAGING REQUIREMENTS SPECIFICATION?

A

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, …)

42
Q

What is the software requirement document?

A
  • 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
43
Q

User stories: remember to ask:

A

WHERE ARE THE DETAILS? YOU SHALL ASK FOR DETAILS IN SMALLER SUB-STORIES

44
Q

What are the 3 C’s of user stories?

A

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

45
Q

What does INVEST IN GOOD STORIES stand for?

A

Independent, negotiable, valuable, estimable, small, testable

46
Q

What is the product backlog iceberg?

A

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)

Software Development and Software Engineering (12 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions