Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
25 Cards in this Set
- Front
- Back
Good Software (4 Factors) |
Maintainability Dependability (Security) Efficiency Acceptability |
|
Generic Products <----> Customized Products |
Generic: Stand-alone system, marketed and sold to anyone who wants it (graphic programs, project management tools, software for specific markets such as a dentist appointment program) Customized: Software commissioned by a specific customer to meet their own needs (embedded control systems, air traffic control software, traffic monitoring systems) |
|
Software specification Software development Software validation Software evolution |
Specification: Customers and engineers define the software that is to be produced and the constraints on its operation. Development: The software is designed and implemented. Validation: The software is checked to ensure that it is what the customer requires. Evolution: The software is modified to reflect changing customer and market requirements. |
|
V-Model |
|
|
User Requirement |
Statements, in a natural language plus diagrams, of what services the system is expected to provide to its users and the constraints under which it must operate. Documents must be understandable by all stakeholders. |
|
System Requirement |
More detailed descriptions of the system's functions, services, and operational constraints. The system requirements should define exactly what is to be implemented. Can be part of a contract. |
|
Relation User-System Requirements |
- Each user requirement has to be addressed in system requirements document. - User requirements can be more open to interpretation, system requirements should be as little ambiguous as possible. - Often several system requirements correspond to a single user requirement. - Use numbers to make correspondence clear. |
|
Types of non-functional requirements (3 main areas, 1-2 examples each) |
Product requirements (usability, dependability, security) Organizational requirements (environmental, operational) External requirements (ethical, regulatory, legislative) |
|
Product requirements
|
Specify or constrain the behavior of the system. Examples include performance requirements on how fastthe system must execute and how much memory itrequires, reliability requirements that set out theacceptance failure rate, security requirements, andusability requirements. Aka "The system shall react to user inputs throughmouse and keyboard in less than 15 seconds." |
|
Organizational requirements |
Broad system requirements derived from policies and procedures in the customer's and developer's organization. Examples include operational process requirements that define how the system will be sued, development process requirements that specify the programming language, the development, the development environment or process standards to be used, and environmental requirements that specify the operating environment of the system. Aka "The system shall be entirely implemented in Java v10.2." |
|
External requirements |
Cover all requirements that are derived from factors external to the systems and its development process. Examples include regulatory requirements that set out what must be done for the system to be approved for use by a regulator, such as a central bank; legislative requirements that must be followed to ensure that the system operates within the law; and ethical requirements that ensure that the system will be acceptable to its users and the general public. Aka "The system shall implement patient privacy provisions as set out in the standard IEEE.2016.12" |
|
Spiral view of the requirements engineering process |
|
|
Problems of requirements elicitation |
- Stakeholders don't know what they really want - Stakeholders express requirements in their own terms. - Different stakeholders may have conflicting requirements. - Organisational and political factors may influence the system requirements. - Requirements change during the analysis process (new stakeholders may emerge, business environment may change) |
|
Use-cases |
Scenario based technique in UML which identify the actors in an interaction and describe the interaction itself. A set of use cases should describe all possible interactions with the system. High-level graphical model supplemented by more detailed tabular description. Sequence diagrams may be used to add details (showing the sequence of event processing in the system) |
|
Sequence diagrams |
Part of the UML and are used to model the interactions between the actor and the objects within a system. Shows the sequence of interactions that take place during a particular use case or use case instance. The objects and actors involved are listed along the top of the diagram. Interactions between objects are indicated by annotated arrows. |
|
State machine models |
Model the behavior of the system in response to external and internal events. Show the system's responses to stimuli (often used for modelling real-time systems) Show system states as nodes and events as arcs between these nodes (event occurs: the system moves from one state to another) |
|
Requirements validation techniques |
- Requirement reviews (systematic manual analysis of the requirements) - Prototyping (using an executable model of the system to check requirements) - Test-case generation (developing tests for requirements to check testability) |
|
Requirement reviews |
- Validity: Does it provide the functions needed - Consistency: Conflicts between requirements? - Completeness: All required functions included? - Realism: Can the requirements be implemented given budget and technology? - Verifiability: Can the requirements be tested? - Comprehensibility: Is the requirement properly understood? - Traceability: Is the origin of the requirement clearly stated? - Adaptability: Can the requirement be changed without a large impact on other requirements? |
|
Requirements management |
The process of managing changing requirements during requirements engineering and system development (new requirements emerge as a system is being developed and after it has gone into use) Keep track of individual requirements Maintain links between dependent requirements (you can assess the impact of requirements changes) Need for a formal process for making change proposals and linking these to system requirements. |
|
Functional Requirements
|
–services the system should provide
–how the system should react to particular inputs –how a system should behave in particular situations –may state what a system should not do –>mainly user requirements not always!!! |
|
Non–Functional Requirements
|
–constrains on the services
–timing constrain, standards, etc –can affect the whole system architecture of a system –often apply to the system as a whole –Not always clear which system components affects which non–functional requirement |
|
Requirements completeness and consistency
|
Complete: they should include descriptions of all facilities required
Consistent: there should be no conflicts or contradictions in the descriptions of the system facilities Both at the same time is just a dream wink emoticon |
|
Make requirements testable
|
–Imprecise requirements are difficult to test
–impressions can be reasons for arguments(court) –> cost money –Always make testable requirements –Always make requirements explicit –non–fun.–req. are often more difficult to identify and test e.g. Speed, Size, Ease of use, Reliability, Robustness, Portability |
|
Requirements and design
|
–In practice requirements and design are inseparable
e.g. The use of a specific architecture to satisfy non–functional requirements may be a domain requirement |
|
Sequence diagrams
|
–Sequence diagrams are part of the UML and are used to model the interactions between the actors and the objects within a system
–A sequence diagram shows the sequence of interactions that take place during a particular use case or use case instance –Objects and actros involved are listed along the top of the diagram (Interaction indication with arrows) |