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

2. 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

3. 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

4. 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!

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

6. 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)

7. 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”

8. 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”

9. 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

10. 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

11. 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

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

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

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

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

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

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

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

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

20. 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

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

22. Example #10
Ability to comply with accessibility standards

23. 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)

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

25. conclusion
Contact information: Steven Barnhart,