In the world of requirements, even if you do a great job gathering and analyzing requirements, there will still be a couple of gray areas. There may be a couple of reasons for this. The main reason is that this is a new system that you are developing to replace an old one (or a system of workflows), therefore, there will be some unknowns. When writing requirement documentation, you want to ensure that you capture those and present them to your client. These are known as assumptions, dependencies, and constraints.
Functional requirements detail the behavior of the intended system. This is from the workflow to the end-user interface. You want to ensure that each functional requirement that you capture is just that.
Non-functional requirements are the requirements that stakeholders and users haven’t thought of, but you have to because without them, the system will fail. If you don’t collect non-functional requirements, then you will not be creating a system that behaves in the way the users need it to.
When you are capturing functional requirements, you usually create use cases. There are two parts to a use case: 1. Use case diagram and 2. Writing part. Use cases are used to identify and illustrate the different parts of a process.
This article studies and determines the benefits for technical communicators using narrative to compose and edit software requirements specifications. Specifically, this article is an examination of requirements specifications written for a Web-based radiology application serving the medical industry.