NLIT-talk-outline

NLIT Summit 2011

Title

Requirements engineering efforts for LBNE and evaluation of requirements management tools

Abstract

Members of the LBNE project at Fermilab have been evaluating potential tools for creating a unified, consistent set of technical requirements and design parameters using standardized terminology and taxonomy. We have completed a requirements engineering process, and have developed a set of requirements for a software solution with capabilities that include baselining, change control and traceability. Part of this process has benefited from insights derived from other projects at Fermilab. For example, in preparation for Fermilab participation in a joint NASA and DOE project, the Joint Dark Energy Mission (JDEM), Fermilab has developed expertise in requirements management for software engineering using IBM's DOORS product. For LBNE we have evaluated DOORS and the Siemens TeamCenter Requirements Management module. We will report on the LBNE requirements engineering process, lessons learned from JDEM, the results of the software evaluation, and our progress on documenting our project's requirements in preparation for a CD-1 Review.

What is Requirements Engineering?

A definition (not THE definition): The process of establishing the services (or functions) that the customer (in our case, the scientists in the collaboration) requires from a system and the constraints under which it operates and is developed.

Most references for this term describe its use in the field of software development.

(Below, greatly modified from: http://www.springer.com/computer/swe/journal/766 according to my evolving understanding and process)

RE encompasses:

• determining organization's purposes for requirements documentation
• determining suite of output documents to satisfy purposes
• determining management scheme and representational format of requirements
• eliciting requirements
• determining their hierarchy and interconnections
• documenting them accordingly
• determining procedures for change control and maintenance.

This determines the scope of the project I will discuss.

Intro to LBNE

purpose of expt

P5: "Recent striking discoveries make the study of the properties of neutrinos a vitally important area of research. Measurements of the properties of neutrinos are fundamental to understanding physics beyond the Standard Model and have profound consequences for the evolution of the universe."

A particularly important development, thanks to a remarkably broad suite of experiments, is the discovery that the three kinds, or "flavors", of neutrinos have tiny masses and can oscillate (morph from one kind to another), contrary to the Standard Model. The oscillation takes place over a distance of about 1000 km, therefore measurement of oscillation parameters requires a neutrino source at one end of a 1000-km baseline, and a detector at the other.

brief description

The proposed Long-Baseline Neutrino Experiment will comprise a new, intense neutrino beam driven by the Fermilab Main Injector in Illinois, a near detector complex on the Fermilab site to characterize the unoscillated beam, and a massive far detector > 1,000 km away in the Homestake Mine in South Dakota. LBNE aims to measure the parameters that characterize three-flavor neutrino oscillations, study a phenomenon known as CP-violation, which may help explain the matter-antimatter imbalance, and determine the relative neutrino masses.

If the detector is located deep underground, scientists could also search for proton decay and study the oscillation of neutrinos produced in Earth’s atmosphere. In addition, they could detect neutrinos from a supernova in our galaxy, which astronomers predict occurs about every 40 years. Scientists also could use the neutrino detectors to look for so-called 'relic' neutrinos, those left over from past supernovae.

This experiment thus consists of a set of subprojects: Beam, near detector, far detector and conventional facilities (caverns, buildings, infrastructure) at both sites. To complicate matters further, we are developing conceptual designs for two far detectors based on different technologies. It is likely that we will build only one or the other, however.

Status

LBNE received CD-0 (mission need) approval in January 2010 and has been preparing for CD-1 (conceptual design) approval since. The preparation has involved development of the conceptual design, continued R&D on the newer technologies and on scaling-up of proven technologies to the massive sizes required, reviews of each of the subsystems, and value engineering exercises to bring the cost down in this era of severely limited budgets.

Reviews conducted last fall uncovered a problem with the project's requirements: they did not clearly flow down to the design choices and parameters of the technical components; nor did they trace back clearly to the overall science objectives.

A requirements document was written for each major component of each subsystem, but there had been no centralized effort to standardize, unify or mandate traceability within and between these documents.

Currently, we are determining our reference design for each of the experiment's subsystems, and recasting the requirements in a standardized format with traceability, aiming for CD-1 approval in March of 2012.

Intro to LBNE's Requirements Management effort

Background

• DOE demands for requirement traceability have been increasing in recent years. (I need to understand this better; apparently FNAL is exempt from some of 413 but we do it anyway...)
• In response, DOE projects are increasing their diligence in documenting requirements.
• LBNE underwent a series of reviews called by the Project Manager to assess readiness for CD-1.
• We had a draft CDR (write out) and a (nonuniform) set of requirements documents assembled in preparation.
• Reviewers (scientists and engineers from the international HEP community) pointed out the need for greater traceability; they had trouble understanding what our designs were based on.
• We have undertaken a requirements engineering and re-documentation effort to address this problem.

Objectives

• Establish and implement LBNE standards and procedures for documenting requirements and related objects such as design parameters such that they can be controlled, reviewed, traced and maintained throughout the lifecycle of the Project and Experiment, and archived afterwards.
• Provide input to Fermilab as it looks into implementing a software toolkit for Projects in the future.
• Simplify CDR by single-sourcing the requirements information in separate application (either refer to them as external documents or import the content directly from a source document created by the application).

Process

Finite-duration tasks

completed

• Research best practices for requirements engineering (online searches and documents from requirements management software vendors, discussions with requirements managers of other project)
• http://spacese.spacegrant.org/uploads/Requirements-Writing/Writing%20Good%20Requirements.pdf
• DOORS document: (can't find it now) Quality begins with requirements
• Review various requirements documents so far written for LBNE subprojects
• Review other projects' requirements documents
• Develop set of functional requirements that req management application must satisfy for LBNE

still incomplete

• Discuss possible tools and methods for unifying, standardizing and organizing reqs accordingly
• Evaluate requirements management applications: IBM Rational DOORS (in use by Far Detector site management and by other project at Fermilab) and Siemens TeamCenter (name)
• Evaluate non-functional factors: cost, time-scale for implementation
• Schedule DOORS (preferred) presentation to LBNE management; invite other interested parties at FNAL to attend FIO
• Determine licensing needs, purchase
• Meet with DOORS consultant to optimize DOORS configuration
• Train team to use DOORS client and Web interface
• Import initial data

• roles and responsibilities, work out w management

Ongoing tasks

• Discuss how to improve what we have in order to meet our needs
• Define required output documents
• Establish standards for language, attributes and format of all objects, accordingly
• Categorize objects that are represented in the documents with eye to flow and traceback
• Refine list of object categories (e.g., objective, requirement, design parameter)
• Refine list of requirement types (e.g., physics, engineering, safety)
• Develop instructions and templates for scientists and engineers to use
• Import and maintain data

Input from JDEM/LSST Project

(need slides from Erik G)

Schema

• List of reports to generate
• List of object type definitions
• List of subtypes for object types
• List of attributes and how each is used
• Describe how will dovetail with CDR development

Status

TBD