Skip to main content

System Quality Requirements Engineering Process (SQUARE)

Researcher: Nancy Mead


System Quality Requirements Engineering Process (SQUARE)

It is well recognized in industry that requirements engineering is critical to the success of any major development project. Several authoritative studies have shown that requirements engineering defects cost 10 to 200 times as much to correct once fielded than if they were detected during requirements development. Other studies have shown that reworking requirements defects on most software development projects costs 40 to 50 percent of total project effort, and the percentage of defects originating during requirements engineering is estimated at more than 50 percent. The total percentage of project budget due to requirements defects is 25 to 40 percent.

A recent study found that the return on investment when security analysis and secure engineering practices are introduced early in the development cycle, ranges from 12 to 21 percent, with the highest rate of return occurring when the analysis is performed during application design. NIST reports that software that is faulty in security and reliability costs the economy $59.5 billion annually in breakdowns and repairs. The costs of poor security requirements show that there would be a high value to even a small improvement in this area. By the time that an application is fielded and in its operational environment, it is very difficult and expensive to significantly improve its security.

While much has been written about security requirements in the abstract, the mechanisms to translate the theory into practice have been unclear. If security requirements are not effectively defined, the resulting system cannot be effectively evaluated for success or failure prior to implementation. Security requirements are often missing in the requirements elicitation process. The lack of validated methods is considered one of the factors. If usable approaches to security are developed, and mechanisms to promote organizational use are identified, then the organization can ensure that the resulting product effectively meets security requirements.

The SQUARE Approach

An elicitation and analysis process for security requirements was developed and applied in a series of client case studies. CMU graduate students worked on this project during the summer and fall of 2004. The case study results from the summer were published as SEI reports, and case study results from the fall are in the process of publication. Rough prototype tools were also developed to support the process. The draft process was revised based on the case studies, so that the current nine-step process is as follows:

  1. Agree on definitions.
  2. Identify security goals.
  3. Develop artifacts to support security requirements definition.
  4. Perform risk assessment.
  5. Select elicitation techniques.
  6. Elicit security requirements.
  7. Categorize requirements.
  8. Prioritize requirements.
  9. Inspect requirements.

Proposed Work

The next steps for SQUARE include documentation of the revised method and additional prototyping with clients. This work will be carried out with SEI funding. There are, however, some areas in which collaboration with Cylab and Cylab sponsorship of a student could advance the work quickly. There are several areas to which a Cylab student could readily contribute, once they are on board with the method. The first is further development of the prototype tool into a more robust tool that could be provided to Cylab subscribers. The second is development of tutorial material that could also be provided to Cylab subscribers who wish to teach the method within their organizations. Another possibility is to hold workshop on security requirements engineering, with assistance from the student in organizing the workshop. Prior conference workshops on the subject have been held. The exact student assignment depends on the technical background and interests of the selected student.