Brainscape's Knowledge GenomeTM

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


See full index

Software Engineering > Software Requirements - Case Study > Flashcards

Software Requirements - Case Study Flashcards

Second Partial.

1
Q

What is the software requirements document?

A

The software requirements document states what is required of the system developers.

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

What it’s included in the software requirements document?

A

It should include:

  • Should include user requirements and specification of the system requirements.
  • It’s NOT a design document, it should state WHAT the developers should do, but not HOW they should do it.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Who uses the software requirements document?

A

It’s used by:

  • System customers
  • Managers
  • System engineers
  • System test engineers
  • System maintenance engineers
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

How the software requirements document is used by the “System customers”?

A

They specify the requirements on the document, which should meet their needs. Customers specify changes to the requirements.

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

How the software requirements document is used by the “Managers”?

A

They plan the bid of the project and the development process.

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

How the software requirements document is used by the “System engineers”?

A

They use the requirements document to understand what the system does.

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

How the software requirements document is used by the “System test engineers”?

A

They use the requirements document to develop validation tests of the system.

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

How the software requirements document is used by the “System maintenance engineers”?

A

They use the requirements document to understand the system and it’s parts.

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

The amount of information in the requirements document depends on..?

A

The type of system and the approach to development used.

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

The requirements document of a system developed incrementally will..?

A

Have less detail, because there will be several iterations each involving interviews with the client an other stakeholders.

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

What is a IEEE standard?

A

It’s a requirements document standard that is mostly applicable to the requirements for large systems engineering projects.

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

What IEEE standard will be used in class?

A

IEEE/ANSI 830-1998

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

What are the parts of a requirements document IEEE

A

They are 10 secctions;

  • Preface
  • Introduction
  • Glossary
  • User requirements definition
  • System architecture
  • System requirements specification
  • System models
  • System evolution
  • Appendices
  • Index
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Requirement document: Preface

A

This should define the version history, and the changes made on each version.

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

Requirement document: Introduction

A

This should describe the need for the system, why it’s important to the organization. It also should include all the functions of the system and how it relates with other systems.

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

Requirement document: Glossary

A

This should define the technical terms used in the document.

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

Requirement document: User requirements

A

Here is defined all the services provided by the user. Also all the nonfunctional requirements should be in this section.

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

Requirement document: System architecture

A

This section should present a high-level overview of the anticipated system architecture, showing its functions across the system modules.

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

Requirement document: System requirements specification

A

This should describe the functional and nonfunctional requirements.

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

Requirement document: System models

A

This might include graphical system models that show all the relationships between the system components and the system environment.

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

Requirement document: System evolution

A

This should include assumptions on which the system based and any changes due to hardware evolution, change in user needs and so on.

22
Q

Requirement document: Appendices

A

These should provide information about specific information that is related with the application of the system.

23
Q

Requirement document: Index

A

Indexes of the document.

24
Q

What is the difference between “User requirements” and “System requirements” when writing them down?

A

User requirements are written in a understandable language, that do not have technical background. System requirements are more detailed requirements that may have technical information.

25
Q

Different ways of writing specifications: Natural Language

A

Use of numbered sentences in natural language. Each number express one requirement.

26
Q

Different ways of writing specifications: Structured natural Language

A

The requirements are written on a standard form or template. Each field provides information about an aspect of the requirement.

27
Q

Different ways of writing specifications: Design description language

A

This approach uses a language like programming language, but with more abstract features to specify the requirements.

28
Q

What are functional requirements?

A

They are the “how” the system responds and what it does.

29
Q

What are nonfunctional requirements?

A

All the limitations of the services provided by the system.

30
Q

What is the differences between requirements and design?

A

The requirements state what the system SHOULD DO and the design should describe HOW IT DOES THIS.

31
Q

Different ways of writing specifications: Graphical notations

A

UML, graphic models supplemented with text annotations.

32
Q

Different ways of writing specifications: Mathematical specifications

A

These notations are based on mathematical concepts such as finite-state machines or sets.

33
Q

Which are the activities of the requirements engineering process?

A
  • Requirements elicitation
  • Requirements analysis
  • Requirements validation
  • Requirements management
34
Q

Explain the requirements elicitation

A

It’s focused on having interviews with all the stakeholders.

35
Q

Mention two types of interview.

A
  • Closed: interviews based on predetermined list of questions.
  • Open: interviews where various issues are explored with stakeholders.
36
Q

Parts of an effective interviewing

A
  • Be open minded, avoid preconceived ideas about the requirements.
  • Some really good ideas come out when the interview is focused on the stakeholders.
  • Work with the interviewee using springboard questions or a prototype system.
37
Q

Explain the requirements analysis

A

The analysis of requirements check that all the information obtained from the elicitation is correct.

  • Different stakeholders may have conflicting requirements.
  • Organizational and political factors may influence the system requirements.
  • New stakeholders may emerge and the business environment may change.
38
Q

What are scenarios? What should include?

A

Scenarios are real life examples of how a system can be used.
Scenarios should include:
-A description of the starting situation.
-A description of the normal flow of events.
-A description of what can go wrong.
-Information about other concurrent activities.
-A description of the state when the scenario finishes.

39
Q

Each scenario is described from the point of view of an..?

A

Actor.

A person or a device that interacts with the software

40
Q

Explain the requirements validation

A

Validation is concerned with demonstrating that the requirements define the system that the customer really wants.

41
Q

State five verifications that should be performed in the validation phase.

A
  • Validity: Are the functions provided by the system supporting the customer’s needs?
  • Consistency: Are there any conflicts in the requirements?
  • Completeness: Are all functions/features required by the customer included? If not, is there any cost/benefit analysis?
  • Realism: Can the requirements be implemented given available budget and technology?
  • Verifiability: Can the requirements be checked?
42
Q

Explain the requirements management

A

Is the process of managing changing requirements during the requirements engineering process and system development.

43
Q

Why requirements change?

A

a) New hardware may be introduced, it may be necessary to interface the system with others systems, business priorities may change and new legislation and regulations may be introduced.
b) The people who pay for a system and the users of that system are rarely the same people.

44
Q

What is planning? (Requirements management) Mention some decisions of planning.

A

Planning establish the level of requirements management detail that is required. Some of the decisions:

  • Identification: Each requirement must be uniquely identified so that it can be cross-referenced with other requirements.
  • Change management process: Set of activities that assess the impact and cost changes.
  • Tractability policies: These policies define the relationships between each requirement and between the requirements and the system design that should be recorded.
  • Tool support: Tools that may be used.
45
Q

Explain the phases of “change management”

A

1) Problem analysis and change specification: Analyze if the change is valid, if not request more information, the request may change, may be more specific, or may be dropped.
2) Change analysis and costing: The effect of the change is assessed by tracing how the change will affect the rest of the system. A cost is assigned and a decision is made.
3) Change implementation: The requirements document is changed and if necessary the design and implementation are changed.

46
Q

Define implementation phase

A

This phase converts the specification of the system into an executable.

47
Q

Define design phase

A

Involves the construction of models which help the analyst to understand the functionality of the system and to communicate with customers.

48
Q

Abstract models of a system allow:

A
  • Communicating behavior or functionalities between the requirement analysis and the implementation phase.
  • Help in the documentation process.
  • Help the implementors and designers focus on the structure or architecture of the entire software system.
  • Helps capturing interactions between the system and the external environment.
49
Q

Explain the modeling and system perspectives

A

1) External: represents the context or environment of the system.
2) Interaction: represents the interactions between a system and its environment, or between the components of a system.
3) Structural: represents the organization of a system or the structure of the data that is processed by the system.
4) Behavioral: represents the dynamic behavior of the system and how it responds to events.

50
Q

Mention the visual modeling capabilities

A
  • Captures business processes by defining the software system requirements from the user’s perspective.
  • Displays modeling elements in many ways, so that they can be viewed at different levels of abstraction.
  • Capture the logical software architecture independent of the implementation language.
  • Enable reuse of parts of a system or an application by creating components of our design.
51
Q

What is UML?

A

UML stands for United Modeling Language. It combines the best of:

  • Data modeling concepts.
  • Business Modeling
  • Object Modeling
  • Component modeling
52
Q

Why is UML useful?

A
  • Can make mistakes on paper, before the code is written and debugged.
  • Is a better way of communicating ideas.
  • It’s independent of any particular programming language and supports higher level of collaboration between developers and non-developers.
  • Can help in tapping into a wealth of existing designs that exploits other’s experience.

Software Engineering (1 decks)

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