E5-Requirements? What requirements? How well-written requirements lead to good systems. Steven barnhart, university of southern California, emeritus

Let’s start at the very beginning… What is a software requirement? A need of a stakeholder which must be delivered or solved by the software to achieve some business value A capability of the software to comply with external needs not directly related to achieving some business value

A very good place to start Types of requirements Functional requirements – what the system should do Authentication and authorization Transactions, corrections, auditing, reporting, and historical data External interfaces Business rules, regulatory requirements Non-functional requirements – how should the system behave Availability, capacity, scalability, reliability Performance, security, usability

WHEN you read you begin with a, b, c The. Glossary. Are these terms synonyms? Course, class, section Registered, enrolled Cross-listed, co-located Co-requisite, concurrent registration Expulsion, dismissal Withdrawal, separation We don’t use our common language in a common way. Define everything!

When yOu sing you begin with do, re, me Characteristics of well-written requirements Clear, concise, and cogent Understandable Unambiguous Testable Independent Atomic* Realistic

Clear, concise, cogent Not containing unnecessary information or wording Ability for the user to enter a department code or a department name, whichever they prefer, in order to bring up a list of courses (Poor) Ability of users to access course listing by department code, or name (Better)

understandable Correct grammatically Use standard conventions “Ability of/for/to…” “The system shall…” Consistent style Preference for use of “shall” rather than “will,” “must,” or “may”

unambiguous A single way to interpret the requirement Common errors: Use of undefined acronyms no matter how commonly used Use of the word “or” Use of the word “and” Placement of qualifying words such as “only”

testable Users should be able to confirm the correct implementation of the requirement Result of testing should be pass or fail, nothing in-between Common errors: Using words such as “safe,” “effective,” “user-friendly,” “unlimited,” “flexible,” “configurable,” “state of the art,” “and/or,” “few,” “most,” “some,” “several,” “TBD,” and “etc.” Using passive voice can introduce testing ambiguity

Independent The understanding of a requirement should not be dependent on any other requirement Common errors: Using unclear antecedents such as “it,” “them,” or “they” as shorthand for elements of other requirements Relying on the sequence of the requirements to convey meaning

Atomic* Only include a single testable element in the requirement Common errors: Using the words “and” or “but” are danger signs Using the word “then” or a proliferation of commas in the requirement are warning signs

realistic Can the requirement be delivered given the current technology, number of resources, or time

Example #1 Ability to add registration requisites at the course level Ability to add registration requisites at the section level

Example #2 Ability to maintain a history of unlimited address changes

Example #3 Ability to determine and store Dean’s List for a term or academic year

Example #4 Ability to track college major, graduate school majors, dates of graduation, and credentials (multiple at each level)

Example #5 Ability for 43,000 students to register via web-registration each term

Example #6 Ability to record lengthy dissertation or thesis title for download for commencement program

Example #7 Ability to implement a balance forward or open item receivables methodology

Example #8 Ability for staff to add/drop students at any point in a term Ability to set timelines on when staff is able to add/drop students

Example #9 Ability to set registration appointments that do not conflict with students’ class attendance times

Example #10 Ability to comply with accessibility standards

Example #11 Ability to handle registration functions for courses and programs not part of the normal registration process such as independent study courses, workshops, continuing education, and consortium courses (students taking classes at other schools)

Example #12 Ability to check for duplicate courses/sections at registration and block or display warning

conclusion Contact information: Steven Barnhart, barnhart@usc.edu