Rename Requirements to Statements

Hi Tony,

Thanks for the feedback. As it stands right now, if a new requirement type (e.g. Statement) doesn't quite match your needs within the software, you could create some customized reporting to refer to your requirements as statements instead. Granted, that doesn't help in the tool, but could make your reports match up better with your goals. (Let us know - support@serlio.com -  if you'd like a hand with either.)

We've had other similar requests in the past - calling actors "roles," "folders" instead of packages, etc. - and I've added this to the list.

What about using the Requirement Type field to indicate it is a Statement? We have found the Type field helpful for quantifying the type of requirement.

We use type to define if the "requirement" represents a pure business rule, functionality, performance, workflow, usability/design, or security requirements. We also have "general" for requirements that don't pertain to a single use case but must be taken into account throughout the entire design phase. I have modified the templates we use to display the Type field.

When a developer comes across a business rule, he or she knows to create external tables that the business can maintain because these requirements are indicative of evolving economies and may change based on business strategy.

Natalie, Its good to hear someone else interested in this topic. I think Case Complete is a powerful tool for managing the requirements discovery process where lots ot different stakeholders are involved. I use it on  NON SOFTWARE PROJECTS---creating ICT solutions, for example working with architects to design buildings. It could be stronger! I'll try and explain why I think this. On the types of  non software projects I work on, early stage meetings can be unstructured with people making all kinds of statements jumping from one topic or interest to another. What I want to do is record the statement and then report how we are going to use/not use it. This prevents stakeholders from repeatedly revisiting something they "mentioned", "suggested" etc and we progress with an audit trail to firm declaritive reqirements. At this stage I find that these statements are more "influences" that will lead to discovering requirements  which are declarable. As you rightly point out I can use a "type" field on REQUIREMENTS objects but I find it distracting when using the tool to use an object called REQUIREMENT for something I think off as a comment, suggestion, issue, event etc.

It seemed to me that Case Complete would lose nothing if it called the "REQUIREMENT" objects "STATEMENTS" then if the developer wanted to regard a particular set of "STATEMENTS" as requirements they would simply group then in a PACKAGE called "Requirements" or use a field to tag them. Secondly if I were to use the tool live in a session with stakeholders and started to capture their thoughts, ideas, concerns, comments etc. in something called "REQUIREMENTS" I would confuse them---"requirement" suggesting something much more than "statement"

It would also be possible to use "STATEMENTS" for setting out "rationales" and any other requirements elements that need to be "weighted" and cross referenced to evaluate the merits of different Scenarios. 

Tony,

Not sure if you're using CaseComplete 2013 yet, but just thought I'd mention to you and anyone else who stumbles on this thread that with CaseComplete 2013 that was released in April, you now have the ability to define filters and new tabs to display the filtered items. What this means is that you could create a filter to show only requirements that have their Type set to "Statement". When you save the filter, it will show the filter name in the tab title, so you could have a Statements tab next to all the other tabs, (like Requirements, Use cases etc.) In addition, any new items you create while in the Statements tab will automatically take on the properties of the filter, in this case they will automatically have the Type field set to Statement, saving you a step.  Perhaps not exactly what you're looking for, but still seems like a step in the direction toward what you're looking for, so thought I'd mention it.

Hi Doug,

I like very much the filters feature and when I am working in the back office it is useful for sorting and finding sets of things. When in the requirements phase I can transcribe all the notes I have from interactions and hold each statement in an individual instance of the Requirement Class.

What I would like to do is use Case Complete live in requirements discovery with users/stakeholders. If I had a class called Statement then there would be no risk of confusion or resistance. But were I to tell users/stakeholders just ignore the fact I am putting your comment, note, significant date etc, in something called a requirement then this would be confusing for 90% of people who have a very fixed perception of what is meant by "requirement"

As you may know I am typically not designing software and use Case Complete to set out approaches and implementation solutions for ICT Infrastructure. There are multiple perspectives that have to be brought into consistent models and implementation is a significant coordination challenge across a number of disciplines. I haven't found a better product than Case Complete for helping me sort things out even though I know it is primarily designed for software developers.

Wouldn't many software projects also have this issue at the early stage?

I can actually use the "Use Case" tab during requirements discovery to capture behaviours brainstorm as there is no conflict with the general use of the term use case. i.e.. they simply see something called  a use case describing the process or sequence of events we are discussing. Had Serlio decided to call use cases "use case requirements" there would be.

Hope this is helpful/interesting.

Tony

Yes it is, thanks Tony.