Software Engineering: Attributes, Processes, and Requirements

Attributes of Good Software

  • Efficiency: Software should not waste system resources like memory and processor cycles.
  • Acceptability: Software should be understandable, usable, and compatible with other systems used by the target users.

Software Engineering Costs

  • Development costs: 60%
  • Testing costs: 40%
  • Evolution costs (for custom software) often exceed development costs.

Software Processes

Plan-Driven and Agile Processes

  • Plan-driven processes: All activities are planned in advance and progress is measured against the plan.
  • Agile processes: Planning is incremental and the process can be easily changed to reflect changing customer requirements.
  • Most practical processes combine elements of both plan-driven and agile approaches.

The Waterfall Model

  • Plan-driven model with separate phases for specification, development, validation, and evolution.
  • Advantages: Planned in advance, good for large systems that don’t require modifications during the process.
  • Disadvantages: Inflexible, difficult to respond to changing customer requirements.

Incremental Development

  • Specification, development, and validation are interleaved.
  • Can be plan-driven or agile.
  • Advantages: Reduced cost of accommodating changing customer requirements, easier to get customer feedback.
  • Disadvantages: Process is not visible, system structure may degrade over time.

Software Requirements

User Requirements

  • Statements in natural language and diagrams describing the system’s services and constraints.
  • Written for customers.

System Requirements

  • Structured document detailing the system’s functions, services, and constraints.
  • Defines what should be implemented and may be part of a contract between client and contractor.

Functional Requirements

  • Statements of services the system should provide and how it should behave in specific situations.
  • May also state what the system should not do.

Non-Functional Requirements

  • Apply to the system as a whole rather than individual features.
  • Examples: Performance, reliability, security, usability.

Requirement Abstraction (Davis’s View)

Requirements should be defined abstractly to allow for multiple contractors to bid on a project and offer different solutions. Once a contract is awarded, the contractor can write a more detailed system definition for the client.

Non-Functional Requirements: Properties and Constraints

  • Constraints on the system’s services or functions, such as timing constraints or development process standards.

Types of Non-Functional Requirements

  • Product requirements: Specify the behavior of the delivered product (e.g., execution speed, reliability).
  • Organizational requirements: Result from organizational policies and procedures (e.g., process standards).
  • External requirements: Arise from factors external to the system (e.g., interoperability requirements, legislative requirements).

Examples of Non-Functional Requirements in Real Cases

  • Product requirement: The system shall be available during normal working hours with downtime not exceeding five seconds per day.
  • Organizational requirement: Users shall authenticate using their health authority identity card.
  • External requirement: The system shall implement patient privacy provisions as set out in HStan-03-2006-priv.