View on GitHub

Notes

reference notes

Introduction to RE

As discussed in chapter 2 system requirements are the description of ehat the system should do and the constraints on system operations.

Requirements engineering (RE) -The process sof finding out, analyzing, documenting and checking these services and constraints.

WHAT IS A REQUIREMENT?

TYPES OF REQUIREMENT

  1. User requirements: Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers. High-level abstract requirements
  2. System requirements: A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented. May be part of a contract between client and contractor. Detailed system descriptions

Example

User requirementss definition

  1. The Mentcare system shall generate monthly management reports showing the cost of drugs prescribed by each clinic during that month.

System requirements specification

1.1 On the last working day of each month, a summary of the drugs prescribed, their cost and the prescribing clinics shall be generated. 1.2 The system shall generate the report for printing after 17.30 on the last working day of the month. 1.3 A report shall be created for each clinic and shall list the individual drug names, the total number of prescriptions, the number of doses prescribed and the total cost of the prescribed drugs. 1.4 If drugs are available in different dose units (e.g. 10mg, 20mg, etc) separate reports shall be created for each dose unit. 1.5 Access to drug cost reports shall be restricted to authorized users as listed on a management access control list.

READERS OF DIFFERENT TYPES OF REQUIREMENTS SPECIFICATION

User requirements:

System requirements:

The readers of the user requirements are not usually concerned with how the system will be implemented and may be managers who are not interested in the detailed facilities of the system.

The readers of the system requirements need to know more precisely what the system will do because they are concerned with how it will support the business processes or because they are involved in the system implementation.

System stakeholders - anyone who:

Stakeholder types:

Functional and nonfunctional requirements

Functional requirements Non-functional requirements
Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.

Functional requirements

MENTCARE SYSTEM: FUNCTIONAL REQUIREMENTS

REQUIREMENTS IMPRECISION

REQUIREMENTS COMPLETENESS AND CONSISTENCY

HOW TO WRITE GOOD FUNCTIONAL REQUIREMENTS

Must include these 3:

  1. Role
  2. Verb
  3. Condition

For example:

Non-functional requirements

NON-FUNCTIONAL REQUIREMENTS IMPLEMENTATION

RELATIONSHIP BETWEEN FUNC AND NON FUNC

Normally func reqs is derived based on the features of system

For non func reqs it were derived or a whole system without focusing on any particular features, But in some situation non func reqs are derived based on the features

Example:

NON-FUNCTIONAL CLASSIFICATIONS

Product requirements Organisational requirements External requirements
Requirements which specify that the delivered product must behave in a particular way. Requirements which are a consequence of organisational policies and procedures. Requirements which arise from factors which are external to the system and its development process.
e.g. execution speed, reliability, etc. e.g. process standards used, implementation requirements, etc. e.g. interoperability requirements, legislative requirements, etc.

EXAMPLES OF NONFUNCTIONAL REQUIREMENTS IN THE MENTCARE SYSTEM:

Product requirement:

GOALS VS REQUIREMENTS

EXAMPLE OF USABILITY REQUIREMENTS

Goal:

Testable non-functional requirement:

METRICS FOR SPECIFYING NONFUNCTIONAL REQUIREMENTS

Property Measure
Speed Processed transactions/second. User/event response time. Screen refresh time.
Size Mbytes. Number of ROM chips.
Ease of use Training time. Number of help frames.
Reliability Mean time to failure. Probability of unavailability. Rate of failure occurrence. Availability.
Robustness Time to restart after failure. Percentage of events causing failure. Probability of data corruption on failure.
Portability Percentage of target dependent statements. Number of target systems.

Requirements engineering (RE) processes

A SPIRAL VIEW OF THE REQUIREMENTS ENGINEERING PROCESS: s

Requirements elicitation

Purpose: to understand the work that stakeholders do and how they might use a new system to help support that work

Two requirement elicitation techniques

  1. Interviewing: talk to people about what they do.
  2. Observation or ethnography: watch people doing their job to see what artifacts they use, how they use them, and so on.

PROCESS ACTIVITIES IN REQUIREMENTS ELICITATION

  1. Requirements discovery
    • interacting with stakeholders of the system to discover their requirements
    • Domain requirements are also discovered
  2. Requirements classification and organization
    • Unstructured collection of requirements, groups related requirements are organized into coherent clusters.
  3. Requirements prioritization and negotiation
    • prioritize requirements and finding resolve requirements conflicts through negotiation
  4. Requirements specification
    • Produce early draft of the software requirements documents
    • Document as input into the next round of the spiral

The cycle end when the requirements document has been produced

SCENARIOS

EXAMPLE OF USER STORIES 1

Photo sharing in the classroom Jack is a primary school teacher in Ullapool (a village in northern Scotland). He has decided that a class project should be focused on the fishing industry in the area, looking at the history, development, and economic impact of fishing. As part of this project, pupils are asked to gather and share reminiscences from relatives, use newspa- per archives, and collect old photographs related to fishing and fishing communities in the area. Pupils use an iLearn wiki to gather together fishing stories and SCRAN (a history resources site) to access newspaper archives and photographs. However, Jack also needs a photo-sharing site because he wants pupils to take and comment on each other’s photos and to upload scans of old photographs that they may have in their families. Jack sends an email to a primary school teachers’ group, which he is a member of, to see if anyone can rec- ommend an appropriate system. Two teachers reply, and both suggest that he use KidsTakePics, a photo-sharing site that allows teachers to check and moderate content. As KidsTakePics is not integrated with the iLearn authentication service, he sets up a teacher and a class account. He uses the iLearn setup service to add KidsTakePics to the services seen by the pupils in his class so that when they log in, they can immediately use the system to upload photos from their mobile devices and class computers.

EXAMPLE OF SCENARIOS 1

Uploading photos to KidsTakePics

Initial assumption: A user or a group of users have one or more digital photographs to be uploaded to the picture-sharing site. These photos are saved on either a tablet or a laptop computer. They have successfully logged on to KidsTakePics.

Normal: The user chooses to upload photos and is prompted to select the photos to be uploaded on the computer and to select the project name under which the photos will be stored. Users should also be given the option of inputting keywords that should be associated with each uploaded photo. Uploaded photos are named by creating a conjunction of the user name with the filename of the photo on the local computer.

On completion of the upload, the system automatically sends an email to the project moderator, asking them to check new content, and generates an on-screen message to the user that this checking has been done.

What can go wrong: No moderator is associated with the selected project. An email is automatically generated to the school administrator asking them to nominate a project moderator. Users should be informed of a possible delay in making their photos visible.

Photos with the same name have already been uploaded by the same user. The user should be asked if he or she wishes to re-upload the photos with the same name, rename the photos, or cancel the upload. If users choose to re-upload the photos, the originals are overwritten. If they choose to rename the photos, a new name is automatically generated by adding a number to the existing filename.

Other activities: The moderator may be logged on to the system and may approve photos as they are uploaded.

System state on completion: User is logged on. The selected photos have been uploaded and assigned a status “awaiting moderation.” Photos are visible to the moderator and to the user who uploaded them.

Requirements specification

The process of writing down the user and system requirements in a requirements document.

WAYS OF WRITING A SYSTEM REQUIREMENTS SPECIFICATION

User requirements are almost always written in natural language supplemented by appropriate diagrams and tables in the requirements document.

System requirements may also be written in natural language, but other notations based on forms, graphical, or mathematical system models can also be used.

The user requirements for a system should describe the functional and nonfunctional requirements so that they are understandable by system users who don’t have detailed technical knowledge. Ideally, they should specify only the external behavior of the system. The requirements document should not include details of the system architecture or design. Consequently, if you are writing user requirements, you should not use software jargon, structured notations, or formal notations. You should write user require- ments in natural language, with simple tables, forms, and intuitive diagrams.

Notation Description
Natural language The requirements are written using numbered sentences in natural language. Each sentence should express one requirement.
Structured natural language The requirements are written in natural language on a standard form or template. Each field provides information about an aspect of the requirement.
Design description languages This approach uses a language like a programming language, but with more abstract features to specify the requirements by defining an operational model of the system. This approach is now rarely used although it can be useful for interface specifications.
Graphical notations Graphical models, supplemented by text annotations, are used to define the functional requirements for the system; UML use case and sequence diagrams are commonly used.
Mathematical specifications These notations are based on mathematical concepts such as finite-state machines or sets. Although these unambiguous specifications can reduce the ambiguity in a requirements document, most customers don’t understand a formal specification. They cannot check that it represents what they want and are reluctant to accept it as a system contract

s

Is it sufficient to use a single way of notation when writing the system requirements specifications? Justify your answer.

NATURAL LANGUAGE SPECIFICATION

Requirements are written as natural language sentences supplemented by diagrams and tables.

Used for writing requirements because it is expressive, intuitive and universal. This means that the requirements can be understood by users and customers.

GUIDELINES FOR WRITING REQUIREMENTS

PROBLEMS WITH NATURAL LANGUAGE

STRUCTURED SPECIFICATIONS

An approach to writing requirements where the freedom of the requirements writer is limited and requirements are written in a standard way. This works well for some types of requirements e.g. requirements for embedded control system but is sometimes too rigid for writing business system requirements.

FORMAT USED FOR SPECIFYING FUNCTIONAL REQUIREMENTS

A STRUCTURED SPECIFICATION OF A REQUIREMENT FOR AN INSULIN PUMP

Format Description
Function Compute insulin dose: Safe sugar level.
Description Computes the dose of insulin to be delivered when the current measured sugar level is in the safe zone between 3 and 7 units.
Inputs Current sugar reading (r2), the previous two readings (r0 and r1).
Source Current sugar reading from sensor. Other readings from memory.
Outputs CompDose-the dose in insulin to be delivered.
Destination Main control loop.
Action CompDose is zero if the sugar level is stable or falling or if the level is increasing but the rate of increase is decreasing. If the level is increasing and the rate of increase is increasing, then CompDose is computed by dividing the difference between the current sugar level and the previous level by 4 and rounding the result. If the result, is rounded to zero then CompDose is set to the minimum dose that can be delivered.
Requires Two previous readings so that the rate of change of sugar level can be computed.
Precondition The insulin reservoir contains at least the maximum allowed single dose of insulin.
Postcondition r0 is replaced by r1 then r1 is replaced by r2.
Side effects None.

TABULAR SPECIFICATION

USE CASES

THE SOFTWARE REQUIREMENTS DOCUMENT

USERS OF A REQUIREMENTS DOCUMENT

User For
System customers Specify the requirements and read them to check that they meet their needs. Customers specify changes to the requirements.
Managers Use the requirements document to plan a bid for the system and to plan the system development process.
System engineers Use the requirements to understand what system is to be developed.
System test engineers Use the requirements to develop validation tests for the system.
System maintenance engineers Use the requirements to understand the system and the relationships between its parts.

REQUIREMENTS DOCUMENT VARIABILITY

Requirements validation

REQUIREMENTS CHECKING:

REQUIREMENTS VALIDATION TECHNIQUES

How can we check that the requirements are valid? There are a number of techniques that can be used to check the requirements:

REQUIREMENTS REVIEWS

REVIEW CHECKS:

Requirements change

REASONS FOR CHANGING REQUIREMENTS

REQUIREMENTS MANAGEMENT

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

New requirements emerge as a system is being developed and after it has gone into use. Therefore, it is required to :

EXAMPLE DEPENDENCY OF REQUIREMENTS:

Requirements management planning

Requirements management planning is concerned with establishing how a set of evolving requirements will be managed. During the planning stage, you have to decide on a number of issues:

  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: This is the set of activities that assess the impact and cost of changes. I discuss this process in more detail in the following section.
  3. Traceability policies: These policies define the relationships between each require- ment 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: Requirements management involves the processing of large amounts of information about the requirements. Tools that may be used range from specialist requirements management systems to shared spreadsheets and simple database systems.

REQUIREMENTS MANAGEMENT TOOLS