Software Engineering
Dr Kingsley Sage
Copyright By PowCoder代写 加微信 powcoder
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 shan’t 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 doesn’t 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代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com