COM1028 SDLC & Requirements

Any person/organization affected by/interested in the system

Establishing:

• the functions and services that a stakeholder requires from a system
• the constraints under which a system operates (operational constraints) and is developed

Statements written for customers:

• of the services the system provides
• of the system's operational constraints
• in natural language (with diagrams)

Must be understood by:

• end-users
• customers without a technical background

A structured document setting out detailed descriptions of the system's functions, services and operational constraints (established in requirements engineering)

Defines what should be implemented

May be part of a contract between the client and contractor

Requirements are detailed with more technical information included

Depend on the:

• type of software
• expected users
• type of system where the software is used

Statements of:

• system services or functionality that should be provided
• what the system should NOT do

How the system should:

• react to particular inputs
• behave in particular situation

Functional User Requirements: high-level statements of what the system should do
Functional System Requirements: detailed descriptions of system services

Defines:

• system properties
• constraints on the services/functions offered by the system
  • e.g timing constraints, constraints on the development process, standards, reliability, response time, storage requirements, I/O device capability, system representations etc.

Often applies to the system to a whole (instead of individual features/services)

• Affects the overall architecture of a system (instead of individual components)
• e.g the system may need to be organized to minimize communications between components to meet performance requirements

May be more useful than functional requirements

• The system may be useless if certain non-functional requirements are not met

May be more specific about process requirements

• Mandating a particular IDE, programming language or development method

Product requirements: specify the delivered product must behave in a particular way

• e.g execution speed, reliability etc

Organisational requirements: a consequence of organisational policies and procedures

• e.g process standards, implementation 

External requirements: arise from factors which are external to the system and its development process

• e.g interoperability requirements, legislative requirements etc

Speed

• Processed transactions per 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 occurance
• Availability

Robustness

• Time to restert after failure
• Percentage of events causing failure
• Probability of data corruption on failure

Portability

• Percentage of target dependent statements
• Number of target systems

Producing a complete and consistent requirements document

• Achievable in principle
• Impossible in practice
  • Due to system and environmental complexity

Completeness: including descriptions of all required facilities
Consistency: no conflicts/contradictions in the description of the system facilities

Goals:

• convey the intentions of the system users (e.g ease of use)
• are helpful for developers

Verifiable non-functional requirements:

• Statements using some measure that can be objectively tested

Writing down user and system requirements in a requirements document

Requirements may be part of a contract for the system development

• It is thus important that the requirements are as complete as possible

When requirements are not precisely stated, problems arise:

• They could be interpreted in different ways by developers and users
• They may be hard to verify
• e.g 'search' could refer to searching for a patient in an individual clinic (developer interpretation) rather than across all appointments in all clinics (user intention)

Invent a standard format and use it for ALL requirements

Use language in a consistent way

• Using "shall" for MANDATORY requirements
• Using "should" for DESIRABLE requirements

Use text highlighting to identify key parts of the requirement

Avoid the use of computer jargon

Include an explanation (rationale) of why a requirement is necessary

1. Definition of the function OR entity

2. Description of inputs and where they come from

3. Description of outputs and where they go

4. Information needed for the computation and the other entities used

5. Description of the action to be taken

6. Pre- and post-conditions (if appropriate)

7. The side effects (if any) of the function

Natural Language

• Requirements are written using numbered sentences
• Each sentence specifies one requirement in natural language

Structured Natural Language

• Requirements are written in Natural Language in a standard form or template
• Each field provides information about an aspect of the requirement

Design Description Languages

• Uses a formal language, but with more abstract features to specify the requirements by defining an operational model of the system
• Can be useful for interface specifications
• Rarely used today

Graphical Notations

• Graphical models (supplemented by text annotations) are used to define the functional requirements for the system
• Commonly used diagrams:
  • UML
  • Use case
  • Sequence diagrams

Mathematical Specifications

• Based on mathematical concepts
  • e.g finite-state machines (FSM), sets
• Unambiguous specifications
  • Can therefore reduce ambiguity in a requirements document
• Most customers don't understand a formal specification

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

Strengths:

• Can be understood by users and customers because it is...
  • Expressive
  • Intuitive
  • Universal

Weaknesses:

• Lack of clarity
  • It can be hard to be precise without making the document harder to read
• Requirements confusion
  • Functional and non-functional requirements can be...
    • Mixed up
    • Hard to state precisely
• Requirements amalgamation
  • Several different requirements may be expressed together

A generic definition of a systems project, involving...

• Planning (Staff list, schedule (Gantt), RAID register, budget)
  • Why build the system? What are it's business needs?
  • Plan and staff the project
• Analysis (Proposal, requirements specification, models)
  • Who, what, when, where will the system be used?
  • Understand what the system should do
• Design (Database design, user interface design, class diagrams)
  • How will the system work?
  • Technical design of the solution
• Development (Code, test plans & tests, installation, training)
  • Implement, test and deliver the system

Strengths:

• Clear stages
• Strong linkage between process, people and solution

Weaknesses:

• Generic in nature
  • Thus does not need to explain exactly what is needed, and when
• Assumes sequential delivery of stages
• Groups key stages together
  • This puts letss emphasis on testing and solving the problem

A system must meet it's requirements (i.e do what it is required to do)

However, problems may change while the solution is being developed

Systems may still fail if the project...

• Takes too long
• Goes over budget
• Does not return any benefit (to the people, or financially)

Heavyweight Methods

• Traditional, sequential approach to software engineering
• Rely on a well-defined problem
• Designed for more stable/static environments
• Driven by planning and design
• Focused on documentation

Lightweight Methods

• Adaptive approaches
• Provide solutions in dynamic environments
• Work on partially-defined problems
• Designed for rapidly changing environments
• Focused on implementation (at the expense of planning and design)

Attributed to Royce (1970)

A phased approach to software development

Emphasis on analysis before development

Ensures that, before code...

• Requirements are well-understood
• Design meets the requirements
• Sign-off required

Verification and Validation (V&V) is important

• Validation checks the requirements meet the user's needs
• Verification tests the system meets it's requirements

Has an extension (the V model) which makes the testing done at each stage more explicit

Based on separate development stages

Outputs are to be produced at each stage, planned in advance

Not necessarily the waterfall model

• Plan-driven incremental development is possible

Iteration occurs within activities

Essential for some system types

Does not meet changing business needs

• i.e software does not evolve quickly enough to reflect these needs

• Emerged in the 1990s to radically reduce the delivery time for working software systems
  • There was a dissatisfaction with the overheads involved in the software design methods of the 1980s and 90s
• Focus on code (instead of design)
  • Therefore, there is minimal documentation
• Based on an iterative approach to software development
• Intended to rapidly develop and deliver software
• Program specification, design and implementation are inter-leaved
• System is developed as a series of versions (or increments)
• Stakeholders are involved in version specification and evaluation
• New versions are frequently delivered for evaluation
• Outputs from the development process are decided through negotiating during the software development process
• Aim is to:
  • Reduce overheads in the software process
    • e.g by limiting documentation
  • Respond quickly to changing requirements without excessive rework

Product development where a software company is developing a small (or medium-sized) product for sale

Custom system development within an organization where:

• there is a clear commitment from the customer to become involved in the development process
• there are few external rules and regulations that affect the software

Virtually all software products and apps are now developed using an agile approach

Often the most important requirement for software systems today

Hard to produce a set of stable software requirements

Software has to evolve quickly to reflect changing business needs

Developmed in the late 1990s

A very influential agile method

Introduced a rane of agile development techniques

Has a technical focus

Hard to integrate with management practice in most organizations

• The method as originally defined is therefore not widely used, even if agile development uses practices from XP

Takes an 'extreme' approach to iterative development, for example...

• New versions may be built several times per day
• Increments are delivered to customers every 2 weeks
• All tests must be run for every build
• The build is only accepted if the tests run successfully

Incremental development is supported through small, frequent system releases

Customer involvement means full-time customer engagement with the team

People not process through pair programming, collective ownership and a process that avoids long working hours

Change supported through regular system releases

Maintaining simplicity through constant refactoring of code

Small releases

• The minimal useful set of functionality (that provides business value) is developed first
• Releases of the system are frequent and incrementally add functionality to the first release

Simple design

• Enough design (and no more) is carried out to meet the current requirements

Refactoring

• All developers should refactor code continuously, as soon as possible code improvements are found
  • This keeps the code simple and maintainable

Collective ownership

• Pairs of developers work on all areas of the system so that:
  • no islands of expertise develop
  • all the developers take responsibility for all of the code (anyone can change anything)

Continuous Integration

• As soon as the work on a task is complete, it is integrated into the whole system
• All the unit tests in the system must then pass

Sustainable Pace

• Large amounts of overtime are NOT considered acceptable
  • The net effect of overtime is often reduced code quality and medium-term productivity

On-Side Customer

• A representative of the end-user of the system (the customer) should be available full-time for the use of the XP team

A (on-side) customer or user is part of the XP development team

• They are responsible for:
  • making decisions on requirements
  • bringing the system requirements to the team for implementation

User requirements are written onto cards as user stories/scenarios

The stories that are to be included in a release are determined by the time available and their relative priority

The development team breaks these cards down into implementation tasks, which become the basis of schedule and cost estimates

The customer chooses the stories for inclusion in the next release, based on their priorities and the schedule estimates

Programmers sit at the same computer to develop software, working in pairs and developing code together, checking each other's work

Pairs are created dynamically so that all team members work with each other during the development process

Strengths:

• Knowledge is shared/spread across the team
  • This reduces the overall risks to a project when team members leave
• Helps develop common ownership of code
• Serves as an informal review process
  • Each line of code is viewed by more than one person
• There is some evidence to suggest it is more efficient than two programmers working separately
• Encourages refactoring
  • The whole team can benefit from improving system code

Tests are written as executable components before the task is implemented

Testing components should:

• be stand-alone
• simulate the submission of input to be tested
• check the results meet the specification

Automated test frameworks make it easy to:

• write executable tests
• submit a set of tests for execution

Testing is central to XP

• The program is tested after every change has been made

XP testing features:

• Test-first development
• Incremental test development from scenarios
• User involvement in test development and validation
• Automated test harnesses
  • used to run all component tests each time a new release is built

Writing tests before code clarifies the requirements to be implemented

Tests are written as programs (rather than data) so they can be executed automatically

A testing framework (e.g JUnit) is usually relied on, so there is always a set of tests that can be quickly and easily executed

All previous and new tests are run automatically when new functionality is added

• This checks the new functionality has not introduced errors, or immediately catches them if there are problems

Weaknesses:

• Programmers prefer programming to testing
  • Short cuts are therefore taken when writing tests (e.g writing incomplete tests that don't check all possible exceptions that could occur)
• Some tests can be hard to write incrementally
  • e.g in a complex user interface, it's hard to write unit tests for the code that implements the 'display logic'
• It is hard to judge the completeness of a test
  • They may not provide complete coverage, even if there are a lot of system tests