As the title says - how to keep track of functionality as the application grows large?
My company use Word-documents where the application has been broken down into chunks called "use cases" - which vary in size and complexity. The problem is that some of them quickly become large and hard to read, as you have to scan between the "happy path" and the edge cases.
We recently started using Visual Studio Team Services for the entire Application Life Cycle - and I wonder if there is a better way than Word-documents - in VSTS or in other systems.
How do you handle this problem in your organization and application? (and if you are using VSTS - do you use any feature of VSTS to tackle the challenge?)
Feeback to answers and comments
Bart van Ingen Schenau Fun answer. I'd like to relate to the application that way - but there are a lot of applications out there that need to be documented. This is one of them.
Christophe Thank you for you comprehensive answer. From its contents I realize this is a diverse subject and not one that to be answered easily. From the other comments I also realize that there are many opinions. I appreciate your links and the terms you mentioned. I've already started reading about BPMN and Use Case 2.0.
Ewan I hoped someone would answer something along your lines. I hoped there would be a standard way of writing automated tests and documentation (at the same time) the same way Test Driven Development (TDD) is done. What I would hope to achive is to immediately see when a change breaks an existing contract, so to speak, of what is supposed to happen.
Feedback to Christophe
The documentation in this app/system contains about 400 use cases. We might have put more or less documentation into each use case than what you would. I suspect more.
I would like to be able to convert most of the documentation into end-to-end-tests. Right now we don't have any end-to-end or UI-tests. We have a lots of unit tests though. Imagine the following:
The x.0 use cases are quite straight forward, but there are quite a few of the x.1 use cases - what we refer to as deviations from the happy path. When counting the 400 uses cases in our product, I didn't include all of the deviations.
I'd like to see a way where the documentation would be the test. Perhaps I could use something like the Gherkin syntax?
Feature: Disallow modifying Product Number when Product is in use The user cannot modify the Product Number when the Product is in use. Background: Given a product with Product Number 123 Scenario: A user attempts to modify a Product Number when the product is in use Given the product being associated with an Order Line When I try to change the Product Number to 456 Then I should see "You cannot change the Product Number, as the Product is already being used" Scenario: A user attempts to modify a Product Number when the product is not in use Given the product not being associated with any other entity When I try to change the Product Number to 456 Then I should see "Changes saved"