How granular do you get with your functional requirements?

[Shiv0921]

Sorry this is a lame question. I have googled it a lot, but I don't know if I'm taking things I've seen too literally and it just leaves me a bit stunned how long this doc is going to be for a pretty standard program. 

What would you go with

1. The system shall continuously acquire data at 1kHz from 5 pressure sensors (PT 112-116)

Or

1. The system shall continuously acquire data at 1kHz from pressure sensor PT 112
2. The system shall continuously acquire data at 1kHz from pressure sensor PT 113
3. The system shall continuously acquire data at 1kHz from pressure sensor PT 114
4. The system shall continuously acquire data at 1kHz from pressure sensor PT 115
5. The system shall continuously acquire data at 1kHz from pressure sensor PT 116

The second is easier to pass/fail individual requirements. But there’s a bunch more things that all of them should do, eg all lines get logged to file, all lines get displayed, all lines have an alarm level, and soon I’m going to have 20 requirements instead of 5 for this tiny part, and for the whole program probably 400 requirements rather than 100. 

I'm trying to make my requirements docs more professional, but I don’t work in a software oriented company so I’d probably have to defend coming out with something so extremely granular... which I could stand by if I could stop doubting which one I ‘should’ do…

I don’t use teststand, maybe if I did I’d be able to see this as what’s most appropriate to plug into there.

[Shiv0921]

Apologies that this isn't a question about the code itself so maybe belongs on another forum, this just feels like the home forum

[jcarmody]

I'm working with a Systems Engineer for the first time in my life.  My team has never done requirements beyond "The system shall perform the acceptance test per document XYZ."  Now we have a very comprehensive set of requirements in Jama.  I hate Jama.

[Yamaeda]

Version 1 is hard to misinterpret and a lot less to write, so i'd go with that.