Stating the requirements – a decisive step in managing software projects. The Standish Group Chaos Report in 2009 has shown that for software development projects: 32% are successfully finalized, 44% are challenges (finalized but exceed their budget and/or allotted time), whereas 24% fail (are abandoned). The Standish Group is a company in the USA renowned for its valuable analysis and reports on software projects. Founded back in 1985, it has a consistent experience in software projects implemented by hundreds of companies. The same report shows the importance of requirements for project development: incomplete requirements are the main cause of project failures and are the number 1 factor that determines budget and/or time over-run.
Requirements
A requirement is usually the expression of a need, a demand or an obligation. An important factor in assuring quality for a project, deliverable or product is correctly establishing what the requirements are. If they are not completely defined and clearly presented, then the project based on them cannot be successful. Getting clear specifications during the first stages of the project prevents cost escalation caused by extra work, customer dissatisfaction and excessive updating throughout the project implementation phase, as well as afterwards, during product maintenance. Obtaining clear project requirements means:
- Who is/are best suited to define requirements?
- What is an appropriate and acceptable requirement?
- How can we prove that each element of the requirement has been attained?
- How do we approach and solve conflicts or technical related differences, financial or organization issues that can arise from this particular requirement?
- How do we agree upon and put into practice documentation writing issues?
Requirements express needs that a project must fulfill. Each requirement conveys a certain expectation for that product. Requirements definition is one of the first steps in project planning. A requirement is different from a specification; a requirement is the starting point in product development, expressing those features that define the product and what it must do. Requirements should not be confused with deliverables, which are the final outputs of a project and the measurable results of some intermediary activities.
A specification contains the description of deliverable characteristics, such as dimensions or performance standards. The general advice is to formulate requirements by incorporating several key features:
SMART Requirements
Specific = they should refer to project related features and nothing else; they should be within the project scope
Measurable = they must be accompanied by certain metrics in order to check whether they have been fulfilled or not
Attainable = they must be realistic, achievable
Relevant = they must be of significance to the project such that, by fulfilling them, one could conclude that the project has been successful
Time-bound = they have to be appropriate from a timely point of view: they must meet project deadlines
Software project lifecycle
Since software is such a distinct product, the IT industry has adapted to the needs generated by these characteristics, by taking in and extending project management models and practices. As a result, today there are a multitude of lifecycle models for software projects; moreover there is a tendency to further customize these models to fit the specific needs of each organization.
There are two so called non adaptive models: the Waterfall model and the V model: the project goes through several stages, each one following the other, like a waterfall: Requirements analysis, Application design, Implementing, Verifying, Maintenance. The second model has a testing stage for each of the five listed. If modifications are needed, none of the two models can successfully deal with it: once the requirements are stated they become frozen, unalterable, thus neglecting one of the key features of software – i.e. its predisposition to change. Nevertheless these models are sometimes used for small projects.
The prototype model suggests building a variant of the final product having some basic functionality; the prototype is then submitted to tests and given to some users for hands-on usage, then collecting feedback. This newly acquired data is used to improve the prototype and resubmitting it to testing. The cycle can start again until satisfactory results are obtained. The risk is to resume the cycle indefinitely (especially when requirements are vague) or, on the contrary, to stop the developing process before reaching the optimal result, just because the prototype “seems” to have all the necessary features.
The incremental model is similar to the prototype model – it consists of linear sequences based on the Waterfall model, resulting in a completely functional product. The product is subjected to testing and at each increment a high-end functionality is added. So the model is module-based.
Agile methods incorporate iterated steps into so called „time boxes” (1-4 weeks per increment). Each step is a mini-project itself, delivering a functional product and the associated documentation; this is an adaptive method, putting more focus on current and near-future activities, allowing for modifications in case of changes. Extreme programming (XP) is one of the most famous Agile methods, based on short iterations, intense testing and simplicity; it is suited for small teams and projects with lots of requirements changes.
Requirements in software projects
Since clear requirements are such an important factor for project success, project management practices have been adapted and extended according to specific needs. As a result, requirements definition is a crucial stage that has been intensely addressed.
User requirements definition is the problem definition stage, consisting of requirements extraction. The sources for requirements can be: market studies, feasibility studies, the domain in which the project will operate, actors (stakeholders), the business process. Some of the requirements capturing techniques are: studies of existing software products, interviews with the actors, scenarios, prototypes of the future system, focus groups, direct observation.
There are two types of user requirements: operational requirements and constraints. Operational requirements describe functionalities that users expect from the system; they are qualified by values such as speed (of operation), capacity, precision. Constraints can be interface requirements – communication interfaces, hardware interfaces, software interfaces, user interfaces -, quality requirements – portability, adaptability, availability, security, safety, standards – or project planning requirements – included in the Project Management Plan.
The user requirements definition stage is followed by the problem analysis phase, software requirements definition. They reflect the developer’s point of view on the problem to be solved. The IEEE 830 standard (Institute of Electrical and Electronics Engineers) describes the contents, the qualities and the advantages of having good software requirements definition; this is up to the developer. There are two types of software requirements: functional requirements – what the system is supposed to do – and non-functional requirements – performance, interface, operation, verification, portability, maintenance, reliability and so on.
In IT projects management practices the two phases that deal with requirements definition have associated documents, with well set contents and structure, established by ESA (European State Agency – who has published a series of standards that define the deliverable documentation for a project): User Requirements Document (URD) and Software Requirements Document (SRD).
* * *
Big software developing companies (Microsoft, IBM, Oracle) recognize the importance of good project management for their activity. As a result, specific practices and methodologies have been adapted to internal needs, creating a multitude of project management models in software.
Requirements are one of the most important factors that can ensure project success; stating them clearly and providing a certain stability can influence project evolution in an obvious way. This conclusion has been proved again and again in IT companies, determining the creation of a specialized job role, that of requirements engineer. This is a position that requires outstanding skills both as an analyst, as well as a designer and developer.
No Comments