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.