Brainscape's Knowledge GenomeTM

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


See full index

Software Engineering > Requirements > Flashcards

Requirements Flashcards

1
Q

What is a software requirement?

A

A software requirement is a property that must be exhibited by something in order to solve some problem in the real world.
It may be a combination from various people at different levels of an organization, and who are involved in a software feature.
The requirements for a system are the descriptors of what the system should do — the services it provides and the constraints on its operation.

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

What are the behavioral properties of software requirements?

A

Requirements must be verifiable as an individual feature as a functional requirement or at the system level as a nonfunctional requirement.
Requirements, testing, and quality personnel must ensure that the requirements can be verified within available resource constraints.

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

What is Requirements Engineering?

A

The process of finding out, analyzing, documenting and checking these services and constraints is called Requirements Engineering.

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

What are the additional attributes of software requirements?

A
  1. Priority rating (to enable tradeoffs)
  2. Status value (to monitor project progress)
  3. Unique identifier (to subject to software configuration management over the life cycle)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

What is a product requirement?

A

A product requirement is a need or constraint on the software to be developed.

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

What is a process requirement?

A

A process requirement is a constraint on the development of the software.
Process requirements may be imposed directly by the development organization, their customer, a third party

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

What is the connection between software and process requirements?

A

Software requirements may implicitly generate process requirements.

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

Where does an organization requirement derive from?

A

An organizational requirement derive from policies and procedures in the customer’s and developer’s organizations.

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

Where does an external requirement derive from?

A

An external requirement derive from factors external to the system and its development process. These include regulatory, legislative, ethical requirements.

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

What is a functional requirement?

A

Functional requirements describe the functions that the software is to execute (i.e. capabilities or features). Functional requirement can be described as a finite set of test steps that validate its behavior.

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

What is a nonfunctional requirement?

A

Nonfunctional requirements constrain the solution. Also known as constraints or quality requirements. This may include performance, maintainability, safety, reliability, security, interoperability.

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

What are the key attributes of functional requirements?

A

Functional specifications should be complete and consistent.

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

What is completeness of a software requirement?

A

Completeness means all services required by the user should be defined.

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

What is consistency of a software requirement?

A

Consistency means requirements should not have contradictory definitions.

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

How do nonfunctional requirements affect software?

A

Nonfunctional requirements may affect the overall architecture of a system rather than the individual components.
A single nonfunctional requirement may generate a number of related functional requirements. It may also generate requirements that restrict existing requirements.

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

How requirements should be stated?

A

Requirements should be stated clearly, unambiguously, and, where appropriate, quantitatively.

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

What is a system?

A

System is an interacting combination of elements to accomplish a defined objective. These include hardware, software, firmware, people, information, techniques, facilities, services, support elements.

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

What are system requirements?

A

System requirement is a requirement for the system as a whole. Requirements for the elements are derived from system requirements.
System requirements are more detailed descriptions of the system’s functions, services, and operational constraints.

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

What are user requirements?

A

User requirements are statements, in a natural language plus diagrams, of what services the system is expected to provide to system users and the constraints under which it must operate.

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

What is the software requirements document?

A

The software requirements document (sometimes called the software requirements specification or SRS) is an official statement of what the system developers should implement

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

What should the software requirements specification include?

A

It should include both the user requirements for a system and a detailed specification of the system requirements.

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

How to avoid outdated software requirements documents?

A

Rather than a formal document, approaches such as Extreme Programming collect user requirements incrementally and write these on cards as user stories. The user then prioritizes requirements for implementation in the next increment of the system.

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

What may the requirements document include?

A

Information about possible system evolution and on anticipated changes.

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

What does the detail level of the requirement document depend on?

A

The level of detail that you should include in a requirements document depends on the type of system that is being developed and the development process used.

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

What is a possible structure of the requirements document?

A
  1. Preface. The expected readership of the document, its version history, a rationale for the creation of a new version and a summary of the changes made in each version.
  2. Introduction. The need for the system. The system’s functions, how it will work with other systems.
  3. Glossary. The technical terms used in the document.
  4. User requirements. The services provided for the user. The non-functional definition system requirements. Product and process standards that must be followed.
  5. System architecture. High-level overview of the anticipated system architecture, showing the distribution of functions across system modules.
  6. System requirements. The functional and non-functional requirements in more specification detail.
  7. System models. Graphical system models showing the relationships between the system components, the system, and its environment.
  8. System evolution. Fundamental assumptions on which the system is based, and any anticipated changes due to hardware evolution, changing user needs.
  9. Appendices. Detailed, specific information that is related to the application being developed.
  10. Hardware requirements.
  11. Index
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

What is requirements specification?

A

Requirements specification is the process of writing down the user and system requirements in a requirements document.

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

List practical considerations on natural language specification.

A
  1. All requirement definitions adhere to a standard format.
  2. Associate a statement of rationale with each requirement.
  3. Language must be used consistently to distinguish between mandatory and desirable requirements.
  4. No assumptions on technical background of the reader.
    5.
28
Q

List practical considerations on natural language specification.

A
  1. All requirement definitions adhere to a standard format.
  2. Associate a statement of rationale with each requirement.
  3. Language must be used consistently to distinguish between mandatory and desirable requirements.
  4. No assumptions on technical background of the reader.
29
Q

What is structured natural language?

A

Structured natural language is a way of writing system requirements where the freedom of the requirements writer is limited and all requirements are written in a standard way.

30
Q

What are the features of the structured specification?

A

It is imposed uniformly.
The structured specification may use programming language constructs to show alternatives and iteration, and may highlight key elements using shading or different fonts.

31
Q

What should be included when specifying functional requirements in a standard form?

A
  1. A description of the function or entity being specified.
  2. A description of its inputs and where these come from.
  3. A description of its outputs and where these go to.
  4. Information about the information that is needed for the computation or other entities in the system that are used (the ‘requires’ part).
  5. A description of the action to be taken.
  6. If a functional approach is used, a pre-condition setting out what must be true before the function is called, and a post-condition specifying what is true after the function is called.
  7. A description of the side effects (if any) of the operation.
32
Q

What best describes the requirements process?

A

Requirements process is not a discrete front-end activity of the software life cycle, but rather a process initiated at the beginning of a project that continues to be refined throughout the life cycle.

33
Q

How software requirements are identified and treated by the requirements process?

A

The requirements process identifies software requirements as configuration items and manages them using the same software configuration management practices as other products of the software life cycle processes.

34
Q

What are four high-level actives of the requirements process?

A

These focus on assessing if the system is useful to the business (feasibility study), discovering requirements (elicitation and analysis), converting these requirements into some standard form (specification), and checking that the requirements actually define the system that the customer wants (validation).

35
Q

How are the efforts spent across earlier and later stages of the requirements process?

A

Early in the process, most effort will be spent on understanding high-level business and non-functional requirements, and the user requirements for the system. Later in the process, more effort will be devoted to eliciting and understanding the detailed system requirements.

36
Q

What does structured analysis method involve?

A

It involves analyzing the system and developing a set of graphical system models, such as use case models, which then serve as a system specification. The set of models describes the behavior of the system and is annotated with additional information describing.

37
Q

What process models topic is concerned with?

A

Process Models topic is concerned with how the activities of elicitation, analysis, specification, and validation are configured for different types of projects and constraints.

38
Q

What are examples of software stakeholders?

A

Users. It is often a heterogeneous group involving people with different roles and requirements.
Customers. This group comprises those who commissioned the software or who represent the software’s target market.
Market analysts. Marketing people are needed to establish what the market needs and to act as proxy customers.
Regulators. Many application domains are regulated. Software in these domains must comply with the requirements of the regulatory authorities.
Engineers. They have a legitimate interest in profiting from the software development by reusing components in/from other products.

39
Q

How unsatisfiable constraints should be dealt with?

A

It is needed to negotiate tradeoffs that are both acceptable to principal stakeholders and within constraints

40
Q

What is the purpose of the requirements process support and management?

A

It introduces the project management resources required and consumed by the requirements process.
It establishes the context for Initiation and Scope Definition phase. Its purpose is to make the link between the process activities and the issues of cost, HR, training, and tools.

41
Q

What is the purpose of the requirements process quality and improvement?

A

Its purpose is to emphasize the key role the requirements process plays in terms of the cost and timeliness of a software product and of the customer’s satisfaction with it.

42
Q

What does process quality and improvement comprise?

A
  1. Requirements process coverage by process improvement standards and models
  2. Requirements process measures and benchmarking
  3. Improvement planning and implementation
  4. Security/CIA improvement/planning and implementation
43
Q

List four requirements elicitation process activities.

A
  1. Requirements discovery
  2. Requirements classification and organization
  3. Requirements prioritization and negotiation
  4. Requirements specification
44
Q

How to deal with an unstructured collection of freshly discovered requirements?

A

Related requirements should be grouped and organized into coherent clusters using a model of the system architecture to identify sub-systems and to associate requirements with each sub-system.

45
Q

What are the major problems faced during the elicitation process?

A
  1. Stakeholders can’t clearly and consistently express their expectations. They may not know anything about feasibility. Their background and domain may have an impact.
  2. Stakeholders’ requirements may conflict or have commonalities, it is not evident.
  3. Requirements may be proposed due to personal motivation.
  4. The environment is fast changing.
46
Q

What is the requirements discovery process?

A

Requirements discovery (sometime called requirements elicitation) is the process of gathering information about the required system and existing systems, and distilling the user and system requirements from this information.

47
Q

What are two types of interviews?

A
  1. Closed interviews, where the stakeholder answers a pre-defined set of questions.
  2. Open interviews, in which there is no pre-defined agenda. The requirements engineering team explores a range of issues with system stakeholders and hence develop a better understanding of their needs.
48
Q

What information a scenario may include?

A
  1. A description of what the system and users expects when the scenario starts.
  2. A description of the normal flow of events in the scenario.
  3. A description of what can go wrong and how this is handled.
  4. Information about other activities that might be going on at the same time.
  5. A description of the system state when the scenario finishes.
49
Q

What scenarios and use cases are not suitable for?

A

They are not effective for eliciting constraints or high-level business and non-functional requirements or for discovering domain requirements

50
Q

What are principle requirements elicitation techniques?

A
  1. Interviews.
  2. Scenarios. They allow to provide a framework for questions about user tasks by permitting «what if» and «how it is done» questions to be asked.
  3. Prototypes. Is a tool for clarifying ambiguous requirements. They provide users with a context within which they can better understand what information they need to provide.
  4. Facilitated meetings. The purpose is to try to achieve a summative effect, whereby a group of people can bring more insight into requirements than by working individually.
  5. Observation. These techniques are expensive but instructive because they illustrate that many user tasks and business processes are too subtle and complex for their actors to describe easily.
  6. User stories. Refers to short, high-level descriptions of required functionality expressed in customer terms. Contains just enough information to produce a reasonable estimate of the effort to implement it. The aim is to avoid the waste of efforts when requirements become invalid before the work begins.
51
Q

What is requirements validation process?

A

Requirements validation is the process of checking that requirements actually define the system that the customer really wants.
Requirements validation is the process of checking the requirements for validity, consistency, completeness, realism, and verifiability.

52
Q

What types of check should be carried out during the requirements validation process?

A
  1. Validity checks. Additional or different functions may become required. Any set of requirements is a compromise across the stakeholder community.
  2. Consistency checks. Requirements in the document should not conflict.
  3. Completeness checks. The requirements document should include requirements that define all functions and the constraints intended by the system user.
  4. Realism checks. The requirements can actually be implemented. These checks should also take account of the budget and schedule for the system development.
  5. Verifiability. System requirements should be written so that they are verifiable.
53
Q

When a requirement is verifiable?

A

This means that you should be able to write a set of tests that can demonstrate that the delivered system meets each specified requirement.

54
Q

What are the requirements validation techniques?

A
  1. Requirements reviews.
  2. Prototyping.
  3. Test-case generation. Requirements should be testable. If the tests for the requirements are devised as part of the validation process, this often reveals requirements problems. If a test is difficult or impossible to design, this usually means that the requirements will be difficult to implement and should be reconsidered.
55
Q

What is requirements management? What are the activities involved?

A

Requirements management is the process of understanding and controlling changes to system requirements.
1. Keep track of individual requirements and maintain links between dependent requirements to assess the impact of requirements changes.
2. Establish a formal process for making change proposals and linking these to system requirements.
The formal process of requirements management should start as soon as a draft version of the requirements document is available.

56
Q

What does requirement management planning involve?

A
  1. Requirements identification. Each requirement must be uniquely identified so that it can be cross-referenced with other requirements and used in traceability assessments.
  2. A change management process. The set of activities that assess the impact and cost of changes.
  3. Traceability policies. Define the relationships between each requirement and between the requirements and the system design that should be recorded. The traceability policy should also define how these records should be maintained.
  4. Tool support.
57
Q

What is the purpose of change management? Why should a formal process be used for it?

A

Change management is essential because you need to decide if the benefits of implementing new requirements are justified by the costs of implementation.

In a formal process for change management all change proposals are treated consistently and changes to the requirements document are made in a controlled way

58
Q

What are three stages of change management process?

A
  1. Problem analysis and change specification. The problem or the change proposal is analyzed to check that it is valid. This analysis is fed back to the change requestor who may respond with a more specific requirements change proposal, or decide to withdraw the request.
  2. Change analysis and costing. The effect of the proposed change is assessed using traceability information and general knowledge of the system requirements.
  3. Change implementation. The requirements document and, where necessary, the system design and implementation, are modified.
59
Q

How can requirements be classified?

A
  1. Functional or nonfunctional
  2. Is derived from one or more high-level requirements or an emergent property, or is being imposed directly on the software by a stakeholder or some other source.
  3. Is on the product or the process. The former can constrain the choice of contractor, the process to be adopted, the standards to be adhered to.
  4. Priority. Priority has to be balanced against the cost of development and implementation.
  5. Scope of the requirement. Scope refers to the extent to which a requirement affects the software and its components. Some have a global scope in that their satisfaction cannot be allocated to a discrete component.
  6. Volatility/stability. Flagging potentially volatile requirements can help establish a design that is more tolerant of change.
60
Q

What is architectural design?

A

Architectural design is the point at which the requirements process overlaps with software or systems design and illustrates how impossible it is to cleanly decouple the two tasks.

61
Q

What is requirements allocation?

A

Requirements allocation is the assignment to architecture components responsible for satisfying the requirements.

Allocation is important to permit detailed analysis of requirements.

62
Q

What does conflict resolution concern?

A

Conflict resolution concerns resolving problems with requirements where conflicts occur between two stakeholders requiring mutually incompatible features, between requirements and resources, or between functional and nonfunctional.

63
Q

What are two conflicts resolving approaches?

A
  1. Requirements prioritization is necessary in order to resolve conflicts and plan for staged deliveries. It may follow a cost-value approach that involves an analysis from the stakeholders defining in a scale the benefits or the aggregated value that the implementation of the requirement brings them, versus the penalties of not having implemented a particular requirement.
  2. The analytic hierarchy process involves comparing all unique pairs of requirements to determine which of the two is of higher priority, and to what extent.
64
Q

What are quality indicators of SRS?

A

Quality indicators can be used to relate the quality of SRS to other project variables. Quality indicators for individual SRS include imperatives, directives, weak phrases, options, and continuances. Indicators for the entire SRS document include size, readability, specification, depth, and text structure.

65
Q

What is an essential property of a software requirement?

A

An essential property of a software requirement is that it should be possible to validate that the finished product satisfies it.

Thus, an important task is planning how to verify each requirement.

66
Q

How to validate acceptance tests for nonfunctional requirements?

A

To validate acceptance tests for nonfunctional requirements they should be analyzed and decomposed to the point where they can be expressed quantitatively.

Software Engineering (5 decks)

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