Federal University of Vale do São Francisco Requirements Specification Quality How to Measure Quality of Requirements Specifications? Ricardo Argenton Ramos rargenton@uwaterloo.ca
Outline � The AIRDoc Approach. � My Postdoc Research - How to Measure Quality of Requirements Specifications? � My 3 Works on progress: � QUALISIS-Br: An Approach to Improve the Quality of Brazilian Health Information Systems � SE-Origami: A method to Teach Software Engineering Process in a Classroom. � Requirement Elicitation Process for a Data Management on a Biofactory �
The AIRDoc Phd thesis defence at october, 2009. Supervisor: Jaelson Castro – UFPE Co-supervisor: João Araújo - UNL AIRDOC is a acronym of: A pproach to I mprove R equirement Doc uments �
Introduction ( the problem ) – 1/2 � Over the past few years, a set of typical issues seems to plague the Use Case Models. For example: � Use case that have been abandoned and are no longer meaningful, � Use case descriptions that are unnecessarily long and complex, � Information that is duplicated, scattered, tangled, � Among others … [Lilly 1999] �
Introduction ( the problem ) – 2/2 The removal of these problems in early stages of software development process reduces the costs associated with software changes. These cost reductions could be three to six times more in later stages than during requirements activities [Pressman 2005], [Sommerville, 2004] . Brooks adds, “The hardest single part of building a software system is deciding precisely what to build.... No other part of the work so cripples the resulting system if it is done wrong. No other part is more difficult to rectify later.” �
How to Solve these Problems? � Inspection techniques ? [Travassos et al., 1999] [Fagan, 1986] � Aspect Orientation ? [Moreira et al., 2005], [Silva, L.; Leite, J. 2005], [Sousa, G; Castro, 2004] � Good practices ? [IEEE Std 830-1998], [IEEE 1061, 1998], [Firesmith, 2007] � Metrics ? [Fenton and Neil, 2000] �
The Proposed Solution We propose to use metrics to discover the potential problems � The use of software metrics reduces subjectivity in the assessment and control of software quality by providing a quantitative basis for making decisions about software quality [IEEE 1061, 1998] �
The Proposed Solution We use the Goal Question Metrics approach to help the metrics application [Basili et al.,1994] �
The Proposed Solution We use the framework proposed by the standard [IEEE 1061, 1998] The GQM approach needs to have a quality model to achieve the goal, question and metrics definitions. �
The Proposed Solution Once, we have measured the appropriate quality factor, our AIRDoc will be able to possible detect some potential problem. Insignts from We propose the solution to the problems in terms of some refactorings to be performed ”Refactoring is the process of restructuring existing computer code without changing its external behavior” ��
Some Recommended Practice for Software Requirements Specifications � Correct ; � Unambiguous ; � Complete ; � Consistent ; � Ranked for importance and/or stability ; � Verifiable ; � Modifiable ; � Traceable ; [IEEE Std 830-1998] ��
AIRDoc - Approach to Improve the Quality of Requirement Documents “funny picture” ��
AIRDoc - Approach to Improve the Quality of Requirement Documents “funny picture” ��
AIRDoc - Approach to Improve the Quality of Requirement Documents “funny picture” ��
AIRDoc - Approach to Improve the Quality of Requirement Documents “funny picture” ��
The AIRDoc “boring picture” ��
A Running Example Adjustment Tax [SERPRO] Update life cycle of documents released System A7 Documents Verify evaluation of the balance of documents Verify deadline in documents with analysis by predecessor Loader on the network suspended Provide period of credit verification Start the treatment of documents Timer released Update of information of Treat cancellation of communications hanging System A10 documents <<include>> <<include>> Treat the releases and <<include>> suspensions of documents with negative balance Verification of hanging documents <<include>> <<include>> Update dependency Communications emission deadlines System of system A11 <<include>> Notify the result of the credit of the document Check the value informed by the user System A9 <<include>> <<include>> Display spreadsheet control <<include>> Display screen of user analysis Analyze period of evaluation of credit Send message System A8 Execute final System A7 <<include>> <<include>> to the user verification System A6 SRF User <<include>> <<include>> Validate share of taxes paid System A5 Consult spreadsheet control out of the country Select document Timer Treat spreadsheet <<include>> <<include>> control Maintain the system parameters and messages Recognize the veracity to credit Timer Start the use of credits electronically recognized <<include>> <<include>> <<include>> <<include>> Continue to use the credit Verify permission to adjust the period of Validate share payments Validate share estimated Control the use of credit of a • Requirement Document released evaluation document Core - SCC <<include>> System A1 <<include>> • Use Case Descriptions Receive identifier of printed System A3 Validate share of payments on Provide information for printed Continue to use the credit of communication estimates and variable finance communication System A2 a document after return ��
The AIRDoc ��
Elaboration of Evaluation Plan ��
Definition of Software Quality Requirements ��
Establish the Quality Evaluation Scope ��
Mapping of: Requirement in Focus and Use Cases Nnnnnnnnnn Nnnnnnnnnn Nnnnnnnn Nnnnnnnnnn Nnnnnnnnn Nnnnnnnn Nnnnnnnn Nnnnnnnnn Nnnnnnnnnnnn Nnnnnnnnn Nnnnnnnnnnnnnn Nnnnnnnnnnnn Nnnnnnnnnnnn Nnnnnnnnnnnnnn Nnnnnnnnnnnnnn Nnnnnnnnnnnnnn Nnnnnnnnnnnnnn Nnnnnnnnnnnnnn Requirement In Focus Use Case Diagram ��
Template to Describe the Requirement in Focus < Identify the requirement in focus by a name. Create a list with the name(s) of use case(s) that are directly related with Requirement in the requirement in focus. In some cases focus it is necessary to describe the steps that are in other use cases.> use cases: 1 - “Display spreadsheet control”, “Display 2 - “Display screen of user analysis” Requirement” ��
Template to describe the Source from the Requirement in Focus <Describe the information about the source, such as: - description about the stakeholder who Source from originated the requirement; Requirement - type of source (interview, annotation, protocols, in Focus laws, rules, etc.); Include the description where the requirement existence is evidenced.> Stakeholder - SRF User. The sources from the requirement in focus are Source from dispersing on: “Display - the laws nº 11.773/2008 (DOU of 18.9.2008) Requirement” and 10.833/2003 (DOU of 30.12.2003) - meeting reports from the SERPRO Units. ��
Template of the evaluation goal <the quality Evaluate in <scope> of <requirement in focus> attribute> Evaluate in Adjustment the maintainability of the display requirement Tax ��
The AIRDoc ��
Definition of GQM Activities ��
Selection/Definition of Quality Model The Goal Quality Attribute Quality Attribute Quality Attribute Quality Attribute Direct Metric(s) Direct Metric(s) Direct Metric(s) Sub Attribute Sub Attribute Sub Attribute Metric Metric Metric [IEEE 1061, 1998] ��
An Example of Quality Model Maintainability Flexibility Understandability Separation of Size Coupling Requirements M2a – number M2b – number of use cases of steps ��
Definition of Questions Quality attribute Question Source of the Answer <question(s) that when answered will provide the insights necessary to achieve the goal. The questions will be <the sources (metrics or other answered basically by the <name of the attribute questions) that need be words: Good, Medium or Bad> or sub attribute > achieve to answer the question> Template: How good is the <quality attribute> from the <requirement in focus>? Q1.1. How good is the size from the display requirement? How good is the Q1.2. How good is the understandability from separation of requirements Understandability from the display requirement? the display Q1.3 - How good is the requirement? coupling from the display requirement? ��
Recommend
More recommend
