[SOLVED] CS Software Engineering

Software Engineering
Dr Kingsley Sage

Copyright By Assignmentchef assignmentchef

Requirements engineering
Functional and non-functional requirements Software requirements document
Requirements specification

Requirements engineering
As we saw, a set of statements of what the system is supposed to do in terms that make sense to the developers
But not yet a DESIGN document that will come later
Can take a lot of effort to produce a really good requirements
Is it always worth the effort?

It all rather depends
What is we were developing:
A flight control system for an aircraft A smartphone game

Big solutions need big documents
The flight control system is: Complex
Has a long working life
Must be very reliable
Must be maintainable
Has legal controls to consider Is safety critical
The smartphone app is: Smaller
Has a short expected lifespan
Subject to creative whims and shifts

Suggests that
There are two broad approaches to the actual development
Waterfall: classical highly structured approach
Agile: lower documentation, high creativity approach
And there are also hybrid approaches
Your coursework is likely to have hybrid aspects

Lifestory of a requirements document

Typical document structure
Preface / Introduction
Glossary: key terms
User requirements: we have these already
System architecture: high level only
System requirements: functional / non-functional
Models: diagrams that help us understand
Evolution: how do we see this system developing (might inform design)
Appendices / Index

How to write requirements
There is a certain language to doing this: shall indicates mandatory requirements
should indicates desirable requirements
But is text prose the only valid way of doing things?
Could use:
Natural language / structured natural language
Design description languages (rarely used, arcane, maddening, we shant consider these)
Tabular / form approaches
Mathematical specifications (only suited to very numeric things)

An example
Start with a user requirement (not entirely accurate from an engineering perspective):
A software control system is needed to determine the correct engine thrust level for an aircraft. The level of thrust depends on the altitude, the desired airspeed and whether the aircraft is climbing or descending. If the aircraft is level in flight, the thrust is determined as k x altitude x desired speed, where k is a constant. If the aircraft is climbing, the thrust is increased by up to a maximum of 1.5 times the level flight value. If the aircraft is descending, the thrust is decreased to no less than 0.5 times the level flight value

Natural language
Possible functional requirements
The software shall determine the thrust level using the parameters airspeed, desired speed and altitude, where all parameters are measured in SI units. The parameters shall be provided to the software in a 32 bit accuracy integer data format every second.
The software shall receive a signal from the flight control system to indicate whether the pilot wishes to hold level flight, climb or descend. If the level of thrust exceeds the maximum level possible for the engine, then an error signal shall be sent to the flight control system and the value shall be capped at the maximum possible.
The level flight thrust shall be calculated as k x altitude x desired speed, where k is the known engine constant.
In climbing mode, the extent of climb shall be determined by the flight control system. The thrust level shall be computed by multiplying the level thrust value by no more than a factor of 1.5
And so on

Tabular approach
Functional requirement F1
Description
The software shall determine the thrust level based on data from the flight control system.
Value from flight control system {Level, Climb, Descend} Parameters from flight control system:
Desired speed: m/s, 32 integer format, real time, every second
Altitude: m/s, 32 integer format, real time, every second
K: engine constant, never updated
Engine thrust level:
Level flight mode: k x desired speed x height
Climb mode: up to 1.5 times level flight value Descend mode: no less than 0.5 time level flight value
Error conditions
If thrust demand exceeds maximum possible value:
Send master warning alert to flight control system
Cap thrust value at maximum possible

Mathematical/algorithmic approach
Functional requirement F1
Description
The software shall determine the thrust level based on data from the flight control system.
x = flightMode; // level, climb, descend k = engineConstant;
Every second DO
levelThrust = k x desiredSpeed x altitude If (x = level)
desiredThrust = levelThrust else if (x = climb)
desiredThrust = levelThrust x max 1.5 else if (x = descend)
desiredThrust = levelThrust x min 0.5 END_IF
if (desiredThrust > maxPossible) Send masterAlarm to FCS desiredThrust = maxPossible
Act on desiredThrust END_DO
// determined by FCS // determined by FCS

The point is
There are many ways that we can usefully present the information
It doesnt really matter which we chose, as long as the information is clear
We can devise many variations on these possibilities, and mix them up as needed
As long as the requirements are SMART

So is this an easy process?

The customer is always right
Yes, but also confused, misguided and possibly part of a larger organisation with many different stakeholders
Different stakeholders might not know what they want
Different stakeholder express things in different ways
Organisational and political factors may influence the requirements
Requirements may shift as new stakeholders emerge or the business environment evolves

Requirements elicitation and analysis
Software engineers work with a range of system stakeholders to find out about the application domain, the services that the system should provide, the required system performance, hardware constraints, other systems, etc.
Stages include:
Requirements discovery
Requirements classification and organization Requirements prioritization and negotiation Requirements specification

The process

Process activities
Requirements discovery
Interacting with stakeholders to discover their requirements
Domain requirements are also discovered at this stage
Requirements classification and organisation
Groups related requirements and organises them into coherent clusters
Prioritisation and negotiation
Prioritising requirements and resolving requirements conflicts
Requirements specification
Requirements are documented and input into the next round of the spiral

UML Use Case diagrams
UML: Universal Modelling Language
Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which 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
We will learn more about UML in the coming weeks

UML Use Case example for a medical records system

Getting the requirements is key to the success of a software engineering project
Sometimes takes a lot of discussion to really understand what is needed (hence the spiral model)
Use case diagrams can help us understand the actors and system functions visually
The requirements document is your first really major task for your group coursework
And you really should have started it
Seminar next week looks at developing requirements

CS: assignmentchef QQ: 1823890830 Email: [email protected]