2. Software Requirements and Architecture¶

2.2 Requirements Engineering¶

starts with customer statement of work: informal description of the problem, opinion-based, changeable, fact-finding about the problem, describe the intended behavior of the expected system.
the final outcome of the customer statement of work is a requirements specification document.
The key task of requirement engineering is to formulate a well-defined problem to solve.
A well-defined problem has:
- set of criteria (requirements) that describes if the proposed solution is solving the problem or not.
- description of resources/components that may help to solve the problem.
Requirement Elicitation: requirements gathering => requirements analysis => requirements specifications.
requirements gathering:
- very hard process, since the requirements are rarely precise and complete.
- understand the business context, how system will be used and how it will fit into the business.
requirements analysis:
- analyze user stories and user needs.
- negotiation with the stakeholders to determine priorities.
- tools: useCases
requirements specification:
- the problem statement in a formal ot semi-formal manner to ensure clarity and completeness of requirements.
- describes the functions, quality, constraints on the system-to-be.
- can ba a written document, diagram, useCases, prototypes, etc.
- tools: UML
important: you don’t need to achieve perfection in one stage before moving to the next; you can use incremental and iterative approaches, where you jump between stages as needed.
useCase defines multiple user stories.

2.2.1 Requirements and User Stories¶

standard 830 is document written by IEEE containing guidelines for writing software requirements.
each user story must have a unique id to keep track of progress.
each story must have priority weight (PW) number, small numbers preferable.
The granularity of requirements is an important issue: TDD requires requirements that are individually testable, no requirements should be approved if there are several simultaneous tests that are needed to ensure that the requirement is met (splitting such requirements is a good idea).
use “shall, will, must” with higher priority requirements.
use “should” with lower priority requirements.
it is a good idea to order backlog in way that stories can go form top to bottom one by one.
we write tests for the requirements during requirement analysis stage and called user acceptance tests (UATs).

User Stories¶

user story: a brief description of system functionality as seen by the user.
format: [user-role] + [cabability] + [system-value] eg. “As tenant, I can unlock the door, to enter my apartment.”

Types of Requirements¶

requirements types: functional, non-functional requirements.
functional requirements: define the behavior of the system, usually relate to the system core.
non-functional requirements: describe some quality characteristics, eg. maintain a persistent state of the system in case of power outages.
Term FURPS+ refers to the non-functional requirements:
- Functionality: lists additional functionality.
- Usability: refers to the ease of use, consistency, esthetics, documentation …etc
- Reliability: specifies the frequency of system failures under different conditions, recoverability, predictability, accuracy, mean time to failure, etc.
- performance: computing speed, efficiency, resource consumption, throughput, response time.
- supportability: testability, adaptability, maintainability, compatibility, configurability, installability, scalability, localizability.
non-functional requirements are more susceptible for vague formulations.
more accurate types of requirements:
- Essential: must be implemented for the system to work.
- Desirable: highly desirable, but not mandatory.
- Optional: can be implemented if the time and resources constraints allow, skipped otherwise.
- Future: not be implemented in the current version of the software, should be re-negotiated in the future versions.

2.2.2 Requirements Gathering Strategies¶

you can’t fix it if you don’t know what’s broken.
Agile recommends that stakeholders must be involved in all stages of development, and not only providing requirements then disappear until product is ready.

2.2.3 Effort Estimation¶

estimate effort consumption based on general feeling about the size of each user story (requires domain experience).
use-case-points or user-story-points is a more systemic way to estimate effort consumption.
team velocity: the number of user-story points the team can complete per single iteration (the unit of time), velocity represents productivity.
individual size of user stories is not appropriate because of code reuse.
Agile methodologist recommend avoiding dependencies between user stories

2.3 Software Architecture¶

software architecture: a set of high-level decisions made during the development and evaluation of a software system.
architecture decisions: decisions that made on a global scope in the project, not on a narrow or local scope.
software architecture is NOT a phase of development.

2.3.1 Problem Architecture¶

problems can be decomposed in different ways: projection, partition.
Partition: isolates parts from each others, simplifies by removing relationships between parts.
Projection: simplifies by removing some details from parts while preserving the relationships between them, then represent the details of each part in its own projection.
projection is preferred.
There are three key players in software engineering problems: user who uses the system to achieve a goal, the software system itself, the environment.

2.3.3 Recombination of Subsystems¶

after decomposition, different subsystems are developed and tested individually.
at some point, all decomposed systems need to be recombined and integrated into one system again.
two key issues with recombination:
- cross-platform compatibility, eg. trust and privileges issues.
- concurrent data access in multi-threaded systems.