Scope Management: How to scope bespoke SW Dev Projects

Interesting article on Scope Management throughout the SW Development lifecycle (waterfall):
https://www.forbes.com/sites/quora/2017/12/14/what-are-some-best-practices-for-scoping-software-development-projects/#127b01df1bca

There are tips / items for several project phases above. For example:
Quoting:
"One of the most important things to do during this time is to define very specific goals for the project. For example, instead of “improve X to be more scalable and performant”, a better and more specific goal might be to “improve X by adding unit tests, supporting 20K queries per second, and reducing capped mean of user latency to <= 200ms”. Having very specific goals allows you to ruthlessly cut anything that does not contribute to these goals, so you don’t suffer from feature creep. Along these lines, you might also consider explicitly defining anti-goals, and separating must-haves and nice-to-haves.

Minimize the batch size of the project by (1) setting up clear milestones and checkpoints for the project and (2) making it easy to launch only part of the project. Not only does this help break down the project, it will also allow the team to pause or cut the project early, should another higher priority task come up.

De-risk the project as soon as possible. Two common ways of de-risking a project include (1) working on the riskiest parts upfront and (2) prototype the riskiest parts using dummy data and/or scaffolding. Whenever a new open-source system or external service is used, that usually represents a big risk.

Don’t optimize for total amount of work done, instead, optimize for total amount of impact over time. Once you’ve gotten the riskiest part out of the way, prioritize working on the part of the project that would result in the highest amount of impact immediately."

DIGEST: Requirements Analysis - Further Reading

Additional info on Requirements Analysis (and SW Requirements):

1. The requirements analysis "film": http://silvaonsoftware.blogspot.pt/2016/05/process-software-requirements-team.html
2. To learn some specifics: See your QMS "requirements standard" (INTERNAL; includes best practices and conventions). 
3. Writing good requirements paper here (PDF)
4. Requirement types: http://silvaonsoftware.blogspot.pt/2016/11/requirements-requirements-types.html
5. For even further info: Read books on the subject and related subjects: Requirements analysis, requirements engineering, business process analysis (a broader topic), writing good requirements. "Google" and/or "Amazon" them. 

(@2016-11-23: Fixed link of Req. Std.; 2017-06-08: fixed link)

Paper: Writing good requirements

There are full courses, papers and entire books on the subject.
It is indeed important to get requirements right (either from the customer or to be able to gather them properly from the customer).

Here's an interesting (old) paper on the subject:
http://homepages.laas.fr/kader/Hooks.pdf

Quoting:
"Abstract. The primary reason that people write poor requirements is that they have had
no training or experience in writing good requirements. This paper will address what
makes a good requirement. It will cover some of the most common problems that are
encountered in writing requirements and then describe how to avoid them. It also
includes examples of problem requirements and how to correct them.
(...)
Published in the Proceedings of the Third International Symposium of the NCOSE - Volume 2, 1993. Prepared by the Requirements Working Group of the International Council on Systems Engineering, for information purposes only. Not an official position of INCOSE."

RESOURCE: Security is a Process

Security is a process: It is not just a tool to produce you reports on potential holes (when probably you don't have the time or the skilled persons to browse through the detailed report it generates).

And this is what happens when you don't have the process in place. You will get to the cover page in the news (for the bad reasons):
https://www.publico.pt/portugal/jornal/auditoria-detectou-21-falhas-de-seguranca-no-sistema-informatico-dos-tribunais-21474798

Excellent initiatives at this level (security) are government initiatives like these ones:

• https://en.wikipedia.org/wiki/Cyber_Essentials (UK)
• https://web.nvd.nist.gov/view/ncp/repository (US, from the NIST)
• https://nvd.nist.gov/ncp/repository (the checklists)
• http://www.usccu.us/documents/US-CCU%20Cyber-Security%20Check%20List%202007.pdf (2007, US)

Tools: (INTERNAL):

1. At the "SW and Security Product Assurance technical area" a list of recommended tools can be found and some are security-related: https://delivery.critical.pt/TechAreas/sspa/SitePages/Web%20Application%20Security%20Testing.aspx (accessible from https://delivery.critical.pt/TechAreas/sspa/SitePages/Tools.aspx)
2. Security Testing Tool Example: IBM AppScan: Used to perform automated web application security tests (dynamic). IBM Security AppScan Standard helps decrease the likelihood of web application attacks and costly data breaches by automating application security vulnerability testing. IBM Security AppScan Standard can be used to reduce risk by permitting you to test applications prior to deployment and for ongoing risk assessment in production environments. 

Remember: Your information system is as strong as its weakest link. For instance: If you don't patch your system components that you rely upon (e.g. your RDBMS, Application Servers, File Servers, Web Servers, target Operating Systems) who do you think your customer will turn to when a security flaw turns up?

History: 2017-11-30, updated with SSPA internal resources (and IBM Appscan tool).

The MoSCoW requirements prioritization method

The MoSCoW method is a prioritization technique on which each non-O letter refers to the priority of each requirement (Must have, Should have, Could have, and Would like but won't get). Some RFPs will use this method to state clearly what the proposals shall have, what is a nice to have, what is optional and what could be left for further versions of the information system to be delivered).

For more information: https://en.wikipedia.org/wiki/MoSCoW_method

SMART requirements

It is always interesting to have some kind of quality measure to check the quality of the work we are producing at a certain phase in the waterfall model.

For requirements, each requirement must respect the SMART quality attributes. Here are 2 very good sources explaining the acronym:

• http://www.win.tue.nl/~wstomv/edu/2ip30/references/smart-requirements.pdf (an old but still up to date paper on the subject)
• http://www.iibacolumbus.org/download/chapter_meetings/chapter_meetings_2013/01-09-2013_Kate_Gwynne.pdf (an IBM presentation on the subject).

The "5 lines summary" lies here (Source: ITGM):  

Software Requirements must have some characteristics to fulfill their goals.The most known is that they must be S.M.A.R.T.:  

Specific: A requirement must say exactly what is required (and shall not use weasel words).
Measurable: is it possible, once the system has been constructed, to verify that this requirement has been met ?
Attainable: is it possible, physically, for the system to exhibit that requirement under the given conditions?
Realisable : is it possible to achieve this requirement given what is known about the constraints under which the system and the project must be developed?
Traceable : is the ability to trace (forwards and backwards) a requirement from its conception through its specification to its subsequent design, implementation and test?

PS. Another classification that sometimes is applied to requirements is the MoSCoW requirements prioritization method. 

Process: Requirements Analysis (The team, the standards and the plan)

ENG.2 - Requirements Analysis (Process) is the most used QMS Engineering process for the SW Requirements Engineering phase (not surprisingly) the phase that leads to the Preliminary Design Review (PDR) milestone and its principal deliverable, the Software Requirements Specification (SRS) Issue 1 (Status: Approved).

The process document can be found here.

The Team and the Conventions to be Used

The requirements gathering shall be performed by business analysts, and when needed the team shall be split into mini-teams (minimum team size = 2). The team shall meet internally (including the project management team that could include de PM, TM and other sub-teams leaders) to adjust the granularity and style of the specification they'll be working on (where to stop: at the GUI control, stop at the GUI screen, ...); that includes recommendations like: never use weak expressions, weasel words, how and where to record open issues. All written requirements must be SMART (please note that this acronym has several meanings, for instance look here for a variant, but we're talking of the meaning on this 1995 paper).

Standards and tools to be used during the requirements gathering shall be left written in the SRS (example: Use of Sparx EA for requirements gathering, open issues on the issue tracker, MS Word for the final contents integration including the final Requirements Catalog, typically a list of requirements presented in tabular form, ...).

The SRS document

The 2 most important sections in the SRS are: The requirements catalog and the traceability matrix (requirements - proposed features, as identified in the technical proposal).
It is recommended to start storing analysis information (from this phase and from the subsequent ones) in a centralized place typically called "Analysis Model". Excepting trivial projects (simpler ones) you'll need to have (and know how to use) a modelling tool to store the technical baseline information (requirements, architecture, detailed design, etc.) as well as keeping related new model items with previously existing ones (traceability relationships). A modelling tool helps you also speeding up the creation of the final traceability matrices (and performing traceability analysis).

Planning for Requirements Gathering

The inputs to the process could be (inception information): RFI, RFP, Technical Proposal (the proposal); some additional information sent by the customer (1 GB pen sent after the KOM) that has to be analyzed).

A plan has to be made for the phase, tailored to the scenario you'll be finding (customer maturity, number of customer stakeholders, ...):
- Initial meeting (present scope of project), closure meeting (present the produced SRS, eventually projected)
- Identify interview needs (subdivide themes/subjects based eventually on the proposal WBS decompostion): Who will talk (and decide) on a certain subject.
- Approve the plan with the customer (adjustments have to be made typically, due to scheduling conflicts); revise the plan (and remember to use it and maintain it - up-to-date).
- Interviews: minimum number, 2 per interviewee. CSW mini teams, minimum number of persons: 2; max. 2-3h of interview (make some pauses).
- Reserve time for a first full round of interviews; use the second one to present results from the gathering (project them if possible) and obtain a first commitment / confirmation that what is being written (requirements) is what is to be done. Use the second round to close open issues left from the first meetings.
- Reserve time for: Setup, Meeting, Follow-up (consolidation of texts, open issues recording)
- Reserve time (several days before from the PDR) to final document consolidation (contributions from all teams) and peer review (formal document review).
- Send the document to the customer and ask for formal customer approval (the project sponsor on the customer side could pass it internally to the interviewees so that they help them review the full document).
- Remember to leave time for processing (all) customer comments (or create actions FFR with a proposed date for closure, even if after milestone ends; customer must agree with this line of action that postpones resolutions)
- Only after that approval comes (in a written form) the document is considered V1 Approved. Store those mails (or any other evidences) on the VCS. They could be handy later on.


PS. Remember: "Weasel words are great!" - says the weasel.
PS2. This is one advanced topic and there are lots of (old) good papers and books on the subject, i.e. there are lots of good articles and books on requirements.
For a start: Look for the keywords "Writing Good Requirements" or start by reading Steve McConnell's  "Code Complete".

Remembering Other Important Things

- Also write (and validate) assumptions (not only requirements)
- Leave the open issues recorded (even if on a section of the document, if no clear closure to the issues were timely attained)
- Make sure you have a complete and balanced specification (no grey zones; ambiguity is our greatest enemy on this phase and on all subsequent ones)
- If possible, write implicit requirements
- Run the typographical corrector on the final integrated SRS document (or only on the Requirements Catalog - Some UML tools have spell checking embedded)
- As with any other DL: Peer review the document (with external team members, if possible) before submitting it to te customer's approval
- If possible: Present the document structure and the main parts of its contents to the customer (e.g. project it during a final presentation meeting) before asking for formal approval (Submitted to Approval status)
- Obtain formal approval of the technical baseline (at this phase it consists mainly of the SRS) with the customer (and leave a written record of it on your VCS): ask for a reply via email, send an email stating "As we've talked a few minutes ago by phone the sent version can be considered approved", write it down on external meeting minutes, ...
- Create the SRS V1 (or Issue 1) Status Approved only after that (and resend it to the customer) and after processing and closing all provided comments (issues raised).

Books on Requirements and Writing Requirements Texts

The following topic lists some books on Business Analysis, Requirements Analysis and writing good requirements: Books on requirements.

Also, remember to avoid weasel words or weak expressions. Some automatic tools (spell-checking) could help you spot forbidden expressions in requirements text (like "may", "might", "sometimes", etc. as well as the typical TBC, TBD, FFR, TODO, To Do, etc.).

Also, every requirement shall be SMART (quality attributes to verify for every requirement being written).
Details here: SMART Requirements.