1.

Identify and briefly describe four types of requirements that may be defined for a
computer-based system.
The four types of requirements that may be defined for a computer-based system are
listed as:
1.
2.
3.
4.

User requirements
System requirements
Functional requirements
Non-functional requirements

1. User requirements

The requirements are the statements in a natural language plus diagrams of the
services the system provides and its operational constraints.
2. System requirements

A structured document setting out detailed description of the systems functions,

services and operational constraints. Define what should be implemented. It may be
part of a contract between client and contactor.
3. Functional requirements

These are the statement of the services the system should provide, how the system
should react to particular input and how the system behaves in particular situation.
4. Nonfunctional requirements

Constraints on the services or functions offered by the system such a timing

constraints, constraints on the development process, standards, etc. often these are
applied to the system as a whole rather than individual features or services.
2. Discuss the problems of using natural language for defining user and system
requirements, and show, using small examples, how structuring natural language
into forms can help avoid some of these difficulties.
Problems of using natural language for defining user requirement are:
i.
Lack of clarity
Precision is difficult without making the documents difficult to read.
ii.
Requirements confusion
Functional and non-functional requirements tend to be mixed-up.
iii.
Requirements amalgamates (mixture)
Several different requirements may be expressed together.
i.
ii.
iii.

Some ways to mitigate these problems

Use a standard format (or a form) for the requirements. Makes them easier to read
and understand the role of the sentences within a requirement specification
Use consistent language. E.g., must implies a mandatory requirement, should a
desirable requirement
Avoid use of computer jargon
Natural language is a more serious problem in the specification of
system requirements, where more detail and precision is required.
1

Software Requirements

Structuring the text into standard forms helps here. A form would
include standardized fields; this forces the writer to answer certain
questions, and helps the reader find the answers quickly. A standard
form could include the following fields:

Description of the function or entity being specified in this

requirement
Description of the function inputs, and the constraints on their
values (pre-conditions)
Description of the function outputs, and the constraints on their
values (post-conditions) [1]

3. Describe four types of non-functional requirements that may be placed on a system.

Give examples of each of these types of requirements.
The four types of non-functional requirements that may be placed on a system are as
follows:
i.

ii.

iii.
iv.

Reliability
Reliability specifies the capability of the software to maintain its performance over
time. Unreliable software fails frequently, and certain tasks are more sensitive to
failure (for example, because they cannot be restarted, or because they must be run at
a certain time).
Availability
Availability of a system is typically measured as a factor of its reliability as
reliability increases, so does availability. Availability of a system may also be
increased by the strategy of focusing on increasing testability, diagnostics and
maintainability and not on reliability
Efficiency
Specifies how well the software utilizes scarce resources: CPU cycles, disk space,
memory, bandwidth, etc.
Usability
Ease-of-use requirements address the factors that constitute the capacity of the
software to be understood, learned, and used by its intended users. [2]

4. Suggest how an engineer responsible for drawing up a system requirements

specification might keep track of the relationships between functional and
nonfunctional requirements.
Engineer would have to make a Systems Requirements Document. An Engineer could
provide documents for each functional and non-functional requirement. The Engineer
should use natural language for non-functional requirements and structured language for
functional requirements. The functional requirements are more for developers eyes and
to use. The non-functional requirements are what user wants and what they except to get
out of the software being developed. The engineer would also have to make sure that the
non-functional requirements dont conflict with the functional requirements. [2]
2

Software Requirements

Software Prototyping

Software Requirements

1. Explain why the rapid delivery and deployment of new systems is often more
important to businesses than the detailed functionality of these systems.
A conventional waterfall or specification-based process is usually prolonged and the final
software is delivered to the customer long after it was originally specified. In a fastmoving business environment, this can cause real problems. By the time the software is
available for use, the original reason for its procurement may have changed so radically
that the software is effectively useless. Therefore, for business systems in particular,
development processes that focus on rapid software development and delivery are
essential. [2] Rapid delivery and deployment are sometimes more important than
functionality or long-term software maintainability. Using waterfall model or any
conventional based model is usually long term process and final system is delivered to
the customer long after it was originally specified.

2. Explain how the principles underlying agile methods lead to the accelerated
development and deployment of software.
The principles underlying agile development are:
i.
Individual and interactions over processes and tools. By taking advantages of
individual skills and ability and by ensuring that the development team knows
what each other are doing, the overheads of formal communication and process
assurance are avoided. This means that the team can focus on the development of
working software.
ii.
Working software over comprehensive documentation. This contributes to
accelerated development because time is not spent developing, checking and
managing documentation. Rather, the programmers time is focused on the
development and testing of code.
iii.
Customer collaboration over contract negotiation. Rather than spending time
developing, analyzing and negotiating requirements to be included in a system
contract, agile developers argue that it is more effective to get feedback
from customer s directly during the development about what is required. This
allows useful functionality to be developed and delivered earlier than would be
possible if contracts were required.
iv.
Responding to change over following a plan. Agile developers argue (rightly) that
being responsive to change is more effective than following a plan-based process
because change is inevitable whatever process is used. There is significant
overhead in changing plans to accommodate change and the inflexibility of a plan
means that work may be done that is later discarded. [3]
3. When would you recommend against the use of an agile method for developing a
software system.
Agile methods should probably not be used when the software is being developed by
teams who are not co-located. If any of the individual teams use agile methods, it is very
difficult to coordinate their work with other teams. Furthermore, the informal
communication which is an essential part of agile methods is practically impossible to
maintain. Agile methods should probably also be avoided for critical systems where the
consequences of a specification error are serious. In those circumstances, a system
4

Software Requirements

specification that is available before development starts makes a detailed specification

analysis possible. However, some ideas from agile approaches such as test first
development are certainly applicable to critical systems.
4. Extreme programming expresses user requirements as stories, with each story
written on a card. Discuss the advantages and disadvantages of this approach to
requirements descriptions.
Advantages:
i.
They represent real situations that commonly arise so the system will support the
most common user operations.
ii.
It is easy for users to understand and critique the stories.
iii.
They represent increments of functionality implementing a story delivers some
value to the user.
Disadvantages:
i.
ii.
iii.
iv.

They are liable to be incomplete and their informal nature makes this
incompleteness difficult to detect.
They focus on functional requirements rather than non-functional requirements.
Representing cross-cutting system requirements such as performance and
reliability is impossible when stories are used.
The relationship between the system architecture and the user stories is unclear so
architectural design is difficult. [3]

5. Explain why test-first development helps the programmer develop a better

understanding of the system requirements. What are the potential difficulties with
test first development?
Test-first development requires there to be a clear relationship between system
requirements and the code implementing the corresponding requirements. In test-first
level, the task implementers have to thoroughly understand the specifications so that they
can write tests for the system. Some difficulties are: programmers prefer programming to
testing and sometimes they take shortcuts when writing tests. Also, some tests can be
very difficult to write incrementally. (Example: in complex user interface, often difficult
to write unit tests for the code that implements "display logic" and workflow between
screens.)
6.

Suggest four reasons why the productivity rate of programmers working as a pair is
roughly the same as two programmers working individually.
The four reasons why the productivity rate of programmers working as a pair is roughly
the same as two programmers working individually are as follows:
i.
Pair programming leads to continuous informal reviewing. This discovers bugs
more quickly than individual testing.
ii.
Information sharing in pair programming is implicit it happens during the
process. This reduces the need for documentation and the time required if one
programmer has to pick up anothers work. Individual programmers have to spend
5

Software Requirements

iii.

iv.

time explicitly sharing information and they are not being productive when doing
so. .
Pair programming encourages refactoring (the code must be understandable to
another person). This reduces the costs of subsequent development and change
and means that future changes can be made more quickly. Hence, efficiency is
increased.
In pair programming, people are likely to spend less time in fine-grain
optimization as this does not benefit the other programmer. This means that the
pair focus on the essential features of the system which they can then produce
more quickly. [4]

Formal Specification
1. Suggest why the architectural design of a system should precede the development of
a formal specification.
The architectural design is a means of structuring the system into (relatively) autonomous
parts which can be separately specified using formal or other techniques. This serves to
structure the specification as well as the system. Of course, the specification could be
structured in some other way but then there is a problem of mapping the specification to
the system structure.
2. You have been given the task of selling formal specification techniques to a
software development organization. Outline how you would go about explaining the
advantages of formal specifications to sceptical, practicing software engineers.
To explain the advantages of formal specification to practicing engineers, it is important
to focus on what it brings to the practice of software development rather than on more
abstract advantages such as the ability to mathematically analyze the specification.
Advantages that might be stressed are:
i.
The detailed analysis of the requirements that is necessary to produce a formal
specification. This results in the discovery and resolution of ambiguities and
errors at an early stage in the process.
ii.
The unambiguous specification of interfaces. Interface problems are one of the
major problems in system integration and a reduction in such problems can
significantly reduce software costs.
iii.
The ability to mix formal and informal specifications. The whole system need not
be formally specified but only those parts where most benefit can be gained. [5]

3. Explain why it is particularly important to define sub-system interfaces in a precise

way and why algebraic specification is particularly appropriate for sub-system
interface specification.
A Subsystem is a system in its own right, except it normally will not provide a useful
function on its own, it must be integrated with other subsystems to make a system.
Therefore, interfaced or connecting subsystems are required to make-up the system. The
6

Software Requirements

sub-system specification specifies the requirements for a system and subsystem and the
methods to be used to ensure that each requirement has been met. An algebraic approach
described the system in terms of operations and their relationship. Algebraic
specification is particularly appropriate for sub-system interface specification. Algebraic
specification involves specifying operations on an abstract data types or object in terms
of their inter-relationships. An algebraic specification has a signature part defining syntax
and an axioms part defining semantics.
4. Bank teller machines rely on using information on the users card giving the bank
identifier, the account number and the users personal identifier. They also derive
account information from a central database and update that database on
completion of a transaction. Using your knowledge of ATM operation, write Z
schemas defining the state of the system, card validation (where the users identifier
is checked) and cash withdrawal.
The Z schemas are shown below. There are many different possibilities here depending
on how much information is maintained. This is one of the simplest which assumes that
customers may not withdraw money if there is an insufficient cleared balance in their
account (a cleared balance is where all cheques paid in to the account have been cleared
for payment). [6]
+----BankAccount-----------------------------------|
| CustomerNumber: N
| AccountNumber: N
| DateOpened: Date
| DateClosed: Date
| CustomerPIN: N
| Balance: Money
| ClearedBalance:Money
| AvailabletoWithdraw: Money
+--------------------------------------------------| DateOpened < DateClosed
| ClearedBalance >= Balance
| AvailabletoWithdraw <= ClearedBalance
+--------------------------------------------------+----Validate--------------------------------------| __
| \/ BankAccount
| Account? N
| PIN?: N
| TransactionOK!: boolean
+--------------------------------------------------| Account? = AccountNumber
| PIN? = CustomerPIN
7

Software Requirements

| TransactionOK!
+--------------------------------------------------+----Withdraw--------------------------------------| __
| \/ BankAccount
| Amount?: Money
+--------------------------------------------------| Amount? <= ClearedBalance
| Amount? <= AvailabletoWithdraw
| Balance' = Balance - Amount?
+--------------------------------------------------

References
[1]https://www.coursehero.com/file/p66svoi/6-points-for-how-throw-away-prototypes-aregood-for-large-systems-development-4/

[2] http://broadcast.oreilly.com/2010/02/nonfunctional-requirements-how.html
[3] http://rupeshreddy.com/2011/03/21/software-engineering-chap17/
[4] http://eliasmatimbas.blogspot.com/2014/05/question-and-answers-in-software.html
[5]https://www.coursehero.com/file/p74ljj0/34-Extreme-programming-expresses-userrequirements-as-stories-with-each-story/
[6] http://www.cise.ufl.edu/class/cen5035/exer/eoc.9.txt
[7] http://documents.mx/documents/answers-to-study-questions.html

Software Requirements