Requirements documentation for LIXI

Utilising my requirements engineering skills and my XML knowledge I have successfully implemented templates for requirements at LIXI. The solution included the creation of 3 requirements documents instead of simply the business requirements document they were using; The three documents were: business requirements specification, technical requirements specification and technical requirements specification. These 3 documents were implemented into the requirements engineering process at LIXI’s valuations working group. This was done by reverse engineering the current XML schema. The valuations working group is happy with their new documentation and LIXI other working groups are to follow suit.

Complexity In XML

XML Metrics

Over the past few meeting with Nick we have began the developed of a framework for measuring the complexity of XML projects. We have based our framework on the extensibility manifesto by Rick Jelliffe.

Approach

The extensibility manifesto provides a good overview of the problems that face developers, and hence would provide a good framework to base the application of XML governance.

Using the Jelliffe's outline of the issues behind the extensibility manifesto [Jelliffe2006] as a basis, the following key areas were found:

• Stakeholder requirements
• Fit for purpose

Other Rick issues todo:

• Reality
• Metrics
• Reuse
• Consistency
• Focus and agility
• Bureaucracy
• Be Methodical

Definitions

• Business data requirements - from the business end
• External data constraints - extra constraints for the data from the business end
• Stakeholder data requirements = business data requirements + external data constraints
  
• System data requirements - from the developers end

Stakeholder requirements

The schema must comply with all business requirements and external data constraints.

• All requirements and constraints must be documented and agreed upon
• Traceability and accountability must be maintained on all requirements throughout the development lifecycle
• Stakeholders should be informed of the resource implications of their data requirements and data constraints

Fit for purpose

The schema must be fit to produce the necessary functionality required by the system.
Compliance with business requirements does not necessarily result in a system which is of benefit to the client and fit for their purposes.

Possible solutions

A list of good practices that we can apply to the issues of XML governance.

• Schematron - specify the gap between requirements and the data model
• Usage schemas - determine how the structure is being used. Often the schema is not a proper representation of the usage of a schema is not properly
  
• Progressive validation
• Metrics
• complexity of the schema
• element and attribute count
• Mapping completeness ratio - in fields : out fields
• Mapping additions ratio - from : to
• Configuration items - xlink to other forms of documentation
  
• XML auditability - daily build

References
[Jelliffe2006] Jelliffe, Rick 2006, "XML Governance & Publishing", Open Publish 2006

Requirements Engineering Journal

Requirements Engineering as a Success Factor in Software Projects by Lehner and Hoffmann (2001)
The authors conducted a study of the requirements engineering process in 15 software projects form a diverse range of industries. They investigated the RE practices and process that were used in each team and through questionnaires and interviews, collected data directly from each project’s stakeholders. A very insightful journal will be quoting this a lot!

More research - the inevitable incorrect/imcomplete requirements

The article: Estimating software projects(2001).
This article addressed the issue of the inaccuracy of project cost estimations due to that fact that it is done in the initial stages of the software development process and therefore likely to be based on incorrect or incomplete software requirements. More specifically it details the causes of poor and inaccurate estimation as being a result of imprecise and drifting requirements, new software projects are nearly always different form the last, software practitioners don't collect enough information about past projects, estimates are forced to match the resources available and there is a general lack of acceptance that developing software is an expensive endeavor. It went on to suggest cost estimation techniques and their various success rates.
This article lead me to the following questions: Does this mean that the completed, correct and non-changing requirement document which is need to deliver a successful project is never available at the commencement of a project? And that IT managers have come to expect this and concentrate their effects on the inevitable add ons and complications? Perhaps this is the reason why there is much focus on a project's contract and accountability. Or perhaps I have become too pessimistic :-D

Interesting citations

"The majority of web-based applications have three main attributes that usually differentiate them from more traditional software applications, they are: (a) network intensive, (b) content driven and (c) continuously evolving; these attributes have a profound impact on the way Web Engineering is conducted [22]." (Pressman, 2000)

Pressman's thoughts on web-based development echo my experiences at Allette Systems. Network intensive corresponds to the need for interoperability amount different applications, content driven is the complexity associated with the various data transformations and continuously evolving can be associated the need for compliance to standards that existing web based applications are expected to adhere to.

Research to date

In the initial stages of my project, I have decided to only research about the subject matter through the reading of journals articles, books and other online reputable sources and discussions with experts in the field. This is to further my understanding of the areas of which my topic covers, more specifically requirements engineering and XML development fields. The following are the articles/chapters in books that I have read to date:

• Research Directions in Requirements Engineering by Betty H.C. Cheng and Joanne M. Atlee
• Towards a Requirements-driven Workbench for Supporting Software Certification and Accreditation by Seok-Won Lee, Robin A. Gandhi and Siddharth
• Aspectual Support for Specifying Requirements in Software Product Lines by Harvey Siy, Prasanna Aryal, Victor Winter, Mansour Zand
• Specification of Non-functional Requirements for Contract Specification in
  the NGOSS Framework for Quality Management and Product Evaluation by
  Xiaoqing (Frank) Liu, Manooch Azmoodeh, Nektarios Georgalas
• Requirements development as a modeling activity by Sergey Diev
• Modularisation and Composition of Aspectual Requirements by Awais Rashid, Anna Moreira, Joao Ara0jo
• R. Pressman. Software Engineering: A Practitioner’s
  Approach. Mc-Graw Hill, New York, NY, fifth edition,
  2000. Chapter 29.